English

Network Security and Logging Policies

A common question we hear is what safeguards are in place to protect the users? We will do our best to answer them. This is not an exhaustive list of all proceedures but a brief summary for those who are technically curious.

First off we must stress to everyone IRC is not a secure medium but there are measures every user should take to ensure that they are secure at the client side. Extensive information and personal help is available on the network in the anonymity related channels.

Client Connections

SSL connections are available on all servers on this network including full path SSL on our webchat. Use port 6697 in your client to connect using SSL. As is true with ANY connection to any server on the internet, the connecting IP is visible if you know where to look. All IPs connecting to our network are obfuscated so they cannot be seen by other users. This action is performed automatically using a cloaking module which basically takes a randomly generated key and executes an algorithm to make your IP unrecognizable. The keys are rotated at regular intervals. Also, all registered nicks are configured using NickServ kill function to prevent impersonation.

Logging Policies

Directly stated: no logs that could possibly identify a user are maintained. This includes IRCd logs, services logs, BOPM scan logs, version replies or any system log that may in any way identify a user through normal chatting.

Inspircd will create a startup.log file even when you define no logging tags. This log is sent to /dev/null so is never written to disk. BOPM does not create a scan log at all and the BOPM.log is also sent to /dev/null even though connections detected by the BOPM are not actual users. Services creates log files with the date as part of the extension, making it more difficult to create links to /dev/null. These logs are handled using the shred command. Shredding occurs automatically every 180 seconds. The file is overwritten with random data numerous times, then overwritten with zeros. This makes it very hard for someone to recover any data about our users from our servers.

Security Measures

We run the latest version of Inspircd and Anope available to ensure that we are not vulnerable to any bugs that have been discovered. We check daily for reports of any possible bugs and if one has been discovered we take the appropriate action. In addition to this all system software is kept up to date by use of either a package manager, or where the version of software in repositories is old, we go to the source. Repositories are often behind, so we find ourselves compiling the latest source code.

As you can imagine just because a bug has not been reported or fixed does not mean it does not exist. We take additional measures to ensure that any impact from such an event is minimized. We do this by using various system monitors such as tripwire, logwatch, and network IPS to name a few. Our IRCds run as an unprivileged user and our services daemon runs as a separate user from the IRCd; if one were compromised, the other is safe. In addition to these measures, iptables are used to completely restrict inbound and outbound network access to our fingerprinted hubs and subhubs ensuring that only authorized peers can send and receive data to our core network.

Where possible we run our SSH daemons on different IPs that are never public. SSH access is required for us to manage our servers. We make sure it is locked down as much as possible. We DO NOT allow password authentication to any server in our network; it is key authentication only. Root access is also disallowed over SSH.

Our security systems and proceedures are tested daily and not only by us. We do have the right to defend our servers. This means that if you decide to DoS/DDoS, Nmap/portscan, attempt lame exploits, bruteforce our SSH, bruteforce our oper passwords, you WILL indeed be logged by our IPS/defense systems.

TLS

You are required to use TLS to connect to our network, using TLS 1.2. We prefer server specified ciphers, and give priority to PFS ciphers. When properly used TLS ensures that no one can snoop on the messages sent between you and our servers. Note that all of our server to server links are TLS, servers authenticate each other based on certificate fingerprints to make sure that no one is sitting in the middle of our TLS server to server connections.

Since we use self signed certificates you should be doing the same as our servers do to each other, which is verifying you are actually talking to the right entity and no one is sitting in the middle snooping on everything. You can easily do this by checking that the certificate fingerprint of the server you are connected to matches one of the below (in SHA256):

Sol: 30:E5:BA:9D:EF:53:15:A3:40:4D:B7:64:C5:38:1D:61:64:68:07:2E:3C:20:95:EE:D0:EC:B2:25:13:F4:93:E5
Porn: 03:F9:0B:AF:D5:37:6F:2C:67:92:4D:95:14:D9:C8:2C:65:53:64:4C:F9:2D:AE:A6:44:5C:68:49:71:B2:4B:83
Not doing this means that you may indeed be using TLS, but you could have an attacker doing a man in the middle attack and reading everything sent between you and our servers.

Inspircd prints what cipher you are using on connect:

*** You are connected using SSL cipher "DHE-RSA-AES256-GCM-SHA384"