Cloaking

Cloaking is a way to hide the IP address and hostname of users on IRC. Below you can read in more detail what it is exactly, how it works and how to change the server settings with regards to cloaking.

What is cloaking
With cloaking turned off, a join on IRC looks like this: *** User (~none@d5142341.example.net) has joined #test With cloaking turned on, users will see: *** User (~none@rox-2DCA3201.example.net) has joined #test The host is cloaked (disguised, partially hidden) so other people won't see your real hostname or IP address. This security feature is useful to prevent users from flooding/attacking each other. They can't flood the other person without knowing their real host/IP. The host is not just cloaked in JOIN's, it is hidden everywhere, including in PART, WHOIS and WHO. Only IRCOps can see the real host / real IP.

Cloaking is controlled by user mode +x (like: ) but it is usually turned on by administrators by default (see server configuration below).

Cloaking does not protect against everything
Cloaking helps to protect someone on IRC but there are still other ways to retrieve the IP address of users outside of IRC. A common trick by an attacker would be to paste an URL in the channel. Then, if the victim surfs to it, the attacker can see the victims' real IP address by looking at the webserver logs.

Cloaked IP addresses
When a host does not resolve, only the IP is known. In that case the join won't whow the real IP: *** User (~none@198.51.100.150) has joined #test But will instead look like this: *** User (~none@AAAAAAAA.BBBBBBBB.CCCCCCCC.IP) has joined #test As expected, banning the full host  will ban the IP. But, there are more options available:

For IPv6 the situation is similar where the cloaked host is  and a ban on   bans the a:b:c:D:e:f:g:h IP address, a ban on   bans a:b:c:d:e:f:g:*, and a ban on   bans a:b:c:d:*.

If you want cloaking to use the cloaked IP address style always, even for hostnames that resolve fine, then see next section.

Enabling and forcing cloaking
Admins normally want users to be cloaked by default. This is done by adding  to (through set::modes-on-connect). Both the example configuration and the default settings already have this. If you want to disable the cloaking protection and don't want users to be cloaked by default then remove the  from modes-on-connect.

Even if users are cloaked by default, they can still unset it to disable their own cloaking. If you want to prevent this, so want users never be able to disable cloaking in any way, then you have to add  to set::restrict-usermodes.

Cloaking modules
A cloaked host is generated by a cloaking module. You must load at least one cloaking module. This too, is done by default already via the default modules.default.conf that almost everyone uses. It is also possible to use another cloaking algorithm created by a 3rd party, but not many have been written.

Cloaking keys
The cloaking algorithm requires secret cloaking keys to be set, see set::cloak-keys for more information. It is VERY important to keep the cloak keys secret. If the cloak keys are known by other (bad) people then it is theoretically possible to decode (or rather: brute force) the original host. If your cloaking keys are leaked or stolen then we suggest changing them. Note though, that this makes all current bans on cloaked hosts and IPs ineffective so this has a major impact on bans. There is no way to convert bans with cloak-keys X to bans with new cloak-keys Y. It is therefore best to avoid leaking cloak-keys at all cost!

Both the set::cloak-keys and set::hiddenhost-prefix settings must be the same on all servers. Otherwise, strange things will happen, such as users seemingly being able to join through bans and such.

Forcing to use the IP-style cloaking
Some admins find cloaked hostnames such as  too revealing. They prefer to always use the cloaked IP address style instead such as. If you want that, then set the option set::cloak-method to ip.