Security Tutorial
Contents
- Introduction
- Securing channels using tools available to all networks
- Specifics for ChatSpike Network Services
- Advanced ChanServ tools
- Comments
- Copyright Information and Licensing
Introduction
This document is designed to aid users of IRC networks in securing their channels against outside intrusion by people they would prefer not to enter. The particular example I will use is based around the alliance I currently run channels for on ChatSpike IRC, Dark Legion. To this day, no-one in my knowledge has ever been able to stay in the channel for more than a minute without being booted.
However, being a services admin on the network may seem to give me an advantage over other people who are trying to secure their own channels against intrusion. In this guide, I am going to attempt to show ordinary people how to secure their channels against the most determined of attackers.
In chapter 2, I will show you how the modes available on most networks allow a simple level of security, covering things such as channel keys and invitations, and how to stop people abusing or avoiding bans.
Chapter 3 will cover the basics of IRC Services as they aid ChatSpike users in securing their channels. This will introduce mode locks, Secure ops mode and other quick and easy functions for securing your channel.
Chapter 4 will cover the more advanced possibilities made available by using the channel access lists and automatic kick lists.
For this guide, you may be required to do things to the channel which require certain high privileges or even Channel Founder permissions. If you receive the error Access Denied then this is generally the cause.
Securing channels using tools available to all networks
This section will cover the tools and usermodes available to stop users entering your channel. To do most of these items, you will need to be a channel operator.
The most important tools in a channel operators arsenal are the kick and ban. Using these in combination is the easiest way of keeping a single person out of your channel, but if abused can lead to entire ISP's or even countries being banned. As this is probably a bit excessive, I thought I'd put a little bit in about successful bans. Users, Nicks, hostnames and other background knowledge must come first however.
Consider the following complete unique user identifier:
What does this tell us? Firstly, we know the nickname of the user, located before the ! mark (ol). We also know the users ISP, which in this case is Blueyonder. The middle bit however, may need some explaining. This section is called the username, and it has its roots in the world of unix and other things older than most current chatters. Back then, you could be sure that this section was accurate and tied to the person that was being banned because it was their unix username. This is back when Internet access usually meant a shell account on a university owned or an ISPs computer. This service, which was called Ident, was one provided to the internet at large to discover whether a user was who he said he was. Since the advent of Windows Operating Systems, this service had to be emulated by IRC clients, but they didn't require the user to be truthful about their existence. Some clients also allow this value to be changed by scripts, which leads to a large number of users having very similar usernames. The tilde (~) in this address is important too, as it signifies that the user cannot be positively identified through the Ident service. Some networks require this service to be available to aid their anti-idiot policies, but ChatSpike isn't one of them.
To ban a user, you generally have to specify some part of the users address as a wildcard to catch those people who have changing addresses like dial-up users. There are two wildcards available for use on IRC, and these simply replace the characters in the full hostname. The first, less powerful one is the question mark (?) which replaces a single character... no more, no less. The second, more powerful and potentially more dangerous one is the asterix (*) which matches any number of characters, including none at all. As you can imagine, this is where the accidental banning of entire countries comes from.
Another related tool worth introducing at this point is the exception. This uses a similar syntax to the ban, with the same rules about nicknames, usernames and hostnames. It has the opposite effect, in that it allows people matching the exception to skip any bans which would otherwise apply to them.
To set a ban or exception, use the command
or
| Examples of hostmasks for bans and exceptions | |
|---|---|
| *!*@*.blueyonder.co.uk | This would apply to all BlueYonder customers from your channel. |
| *!*@*.uk | This one catches all UK ISPs. |
| ??!*@* | All two letter nicknames. |
| ?*!*@* | All nicknames at least one character long (same as all nicknames). |
| *!idiot@* | All users called idiot where the ident service is available. |
| *!*diot@*.no | All users with diot at the end of their username from norway. |
| *!*@* | Everyone (You may see this used by channel services to clear channels) |
Using bans and exceptions, it is quite feasible to ban everyone and then make exceptions for all those users who you wish to let into your channel. Personally, I wouldn't recommend it because there are some issues that would need addressing, like how to deal with people who change ISP's.
The natural partner of the ban is the kick, which forcibly removes the person named from the channel. The two are so often used together that more often than not they occupy a combined menu slot in your IRC client. Both mIRC and xchat have the ability to combine the kick and the ban into one movement, and xchat allows to to select the scope of the ban to use as well. mIRC uses a standard type of ban of *!*@*.host. This can be fairly effective, but may be slightly overreaching for channels where a lot of people use the same ISP.
Another tool available to channel operators is the invite and key channel modes. The first one makes the channel such that only users already on the channel can invite others into the channel, which adds a fair bit of security. The second one is the concept of secret keys or passwords, where you need to know a codeword to join the channel. These are potentially very secure, as long as the key doesn't fall into the hands of the people who you want to stay out. As this can happen in a number of ways, I'd recommend that keys are changed on a regular basis.
| Useful Modes | |
|---|---|
| i | makes channel invite only |
| k | makes channel require a key before allowing you on (requires key as parameter) |
| s | hides the channel from /list (secret) |
| t | only channel operators and half-operators can change the topic |
| n | no external messages |
| f | flood protection (requires parameter in the following format - lines:seconds) |
| R | Registered nicknames only |
| m | moderated: only people with voice, halfops or ops may speak |
| N | Nickname changes are not allowed on this channel |
If you wish to set two modes which require additional parameters, you must get the parameters in the right order. I would recommend splitting commands up into two separate orders.
Example: Set a key and a flood restriction on the same command
f comes before k so flood must precede key.
Other modes are available by doing the following command: /helpop ?chmodes
There is one problem with all of these methods, and it is a simple one. If the channel closes because everybody leaves, all channel modes, bans and exceptions are lost. The main way to deal with this is to use a piece of software called a bot, which sits in the channel keeping it open. These tools can also be configured to manage lists of people who should and shouldn't have operator status, and other similar tasks. Unfortunately, there are a great many different types of bot which all have different strengths and weaknesses, so I don't propose to go through setting them up and using them. Some networks have bots attached to servers which are run by the staff of those networks, and if you fulfil some criteria you can apply to have a network bot sit in your channel to manage it while you are off-line.
Other networks have a system available called network services, and again there are different versions and makers on the various networks out there. As this document is focusing on ChatSpike, it is their version of IRC-Services which I will focus on.
Specifics for ChatSpike Network Services
On ChatSpike IRC, the services software that is available to users is fully documented with help files and all the commands have individual documentation. In the future, we may provide a repacked document set which includes these items to users.
What I'm going to do now is to introduce the relevant services quickly and describe simply how they can aid your security.
Firstly is NickServ. Now, it may not be completely obvious how Nickname registration can aid your channels security, but it all starts here. Without a registered nickname, you cannot register channels in your own name or appear on any channels' access lists (which I'll cover later). If you combine this with the channel mode +R, only registered nicknames can join your channel.
Secondly is MemoServ, although I suspect a lot of people are wondering why I wish to cover that here at all. At first glance, it doesn't have any relevance to channel security, but if we consider the channel memo approach it becomes clearer. Using MemoServ with the following syntax will allow you to send messages to anyone in a position to read them:
This requires you to be on the channel access list at level 10 or higher, specifics of which I'll detail later.
On the other hand, this does enable you to send messages to all of those people higher up the access list to you who may be able to modify the ChanServ lists to remove privileges from others or to set AKick bans.
This leaves us with the final service, which is the most important of them all regarding channel security. ChanServ is the Channel Service, and so its tools are of great importance to learning about securing channels. A lot of the following items require channel founder access, or the founder password (which enables a trusted user to elevate their privileges for a single session) to have full effect.
Firstly, I'd like to cover the virtues of channel specific items. These commands and settings will affect all users in the channel equally regardless of what status they occupy in the channel.
| Available options | |
|---|---|
| Founder | Set the founder of a channel |
| Successor | Set the successor for a channel |
| Password | Set the founder password |
| Desc | Set the channel description |
| Url | Associate a URL with the channel |
| Associate an E-mail address with the channel | |
| EntryMsg | Set a message to be sent to users when they enter the channel |
| KeepTopic | Retain topic when channel is not in use |
| TopicLock | Topic can only be changed with TOPIC |
| MLock | Lock channel modes on or off |
| Private | Hide channel from LIST command |
| Restricted | Restrict access to the channel |
| Secure | Activate ChanServ security features |
| SecureOps | Stricter control of chanop status |
| LeaveOps | Do not de-op users on channel entry |
| OpNotice | Send a notice when OP/VOICE commands are used |
| Enforce | Enforce auto-op, auto-voice status |
In chapter 2, I referred to bots as a device for keeping channel settings intact when users were not in your channel. ChanServ also has facilities for some of the things that bots do, in the MLock, TopicLock and Secure / SecureOps functions. MLock can be used to enforce the modes you wish to use, such as +Rikf-m. The modes used are the same as those in the previous chapter, and any modes not currently set will be set by ChanServ itself after the command is run.
The TopicLock option requires all topic changes to go through ChanServ (using /msg ChanServ topic
The remaining two ChanServ settings are where the majority of the security provided by ChanServ comes from. If a channel has the Secure setting switched on, users opening a closed channel are automatically deoped (unless LeaveOps is set) and only the founder is automatically opped on joining the channel. Under SecureOps mode, no-one can be opped or deopped without the approval of ChanServ. Restricted mode adds the requirement that users be approved, or they are kicked and banned from the channel. The next question is how to get that approval from ChanServ.
Associated with every channel registered with ChanServ is an access list, which is a bit like a guest list outside a private party. If Restricted is set, it is like the classical "If your name isn't on the list, you're not coming in". If only Secure is set, it is more like a party with a VIP area: those people who are on the list may receive special treatment (like ops or voice) but it isn't closed to the rest of the world. SecureOps is an extension of the list that throws people out of the VIP if they aren't on the list, even if they're invited guests. On the access list is a number and a nickname, which corresponds to a linked nick in the NickServ database. If you don't have a registered nickname, you can't appear on the access list in any form, other than as a guest.
Access lists are a complicated beast, and the commands are potentially difficult to understand. As a result, the authors of IRC Services added a simple way to add people with the correct privileges quickly. There are 4 commands, each having add, del and list capability: SOP, AOP, HOP and VOP. To make it easier to understand, here is a quick overview of the capabilities of each.
SOP (Super-Operator)
With the exception of the channel founder, these people are gods. In the standard setting, They have the right to modify all settings on a channel, except those set using SET (such as SECURE). SOP members can add other users to all three of the other lists, and are protected from being kicked as soon as they join the channel.
AOP (Auto-Operator)
In the standard settings, these people gain automatic operator privileges, and gain all the rights afforded to them. They can set channel modes and so on, unless a mode lock is in effect (modes held by ChanServ will be automatically set or unset if changed). These people can also add others to the HOP and VOP lists.
HOP (Half-Operator)
By default, these people will be given half-operator status on joining. This is the lowest level for which members can read channel memos, and they can also set a limited number of modes on a channel (mode lock allowing). These people can also modify the VOP list.
VOP (Voice-Operator)
These users are automatically given voice on a channel.
To add someone to these lists, all you have to do is make sure that the user has a registered nickname, and run the following command: /msg ChanServ
. Examples follow.
| /msg ChanServ HOP #channel add Dave | Dave recieves half-op status when he next joins or identifies for his nick. |
| /msg ChanServ VOP #channel add Dave | If this is the same dave and channel as before, he would be taken off the HOP list and put on the VOP list instead. |
| /msg ChanServ VOP #channel del Dave | This command removes Dave from the VOP list. It would not (as in this example) add him back to the HOP list |
Extra commands which may not be relevant to channel security are available in the services help files, which can be accessed by doing /msg ChanServ help commands and /msg ChanServ help set. Access to Set commands requires founder level access.
The other aspect of bots versus service agents is the ability for a bot to automatically kick someone based on a list of hostmasks with a set reason. This functionality is also replicated in ChanServ under the AKick list. Below are the commands to manipulate the AKick list, where mask is a hostmask fitting either ident@host or the complete nick!ident@host. Wildcards are allowed in this list.
This command is to add a hostname to the list. Any nicks matching this list will be automatically kicked by ChanServ with the reason provided. If one is not present the message You have been banned from the channel will be used instead. A ban matching the host provided will also be set to prevent clients using auto-rejoin.
This is the opposite of the Add command, and allows people matching the host to enter the channel.
When a host is added to the AKick list, it isn't automatically kicked from the channel straight away as a saftey measure against over-enthusiastic bans. When this command is run, the agent will kick all people matching the hosts in the list and set appropriate bans as required.
This lists the entries on the AKick list (matching the optional parameter mask or being in the list of numbered entries)
This command is similar to list, and adds more detail to each entry listed.
This tells you how many people are on the AKick list.
Advanced ChanServ tools
The IRC Services software used on ChatSpike is a slightly modified version of IRC-Services 5 (www.ircservices.za.net), where the modifications are mainly new features for some of the internal communities on the network and tweaks to the default access levels to make it more similar to the version 4 settings. This means that while some settings used on v4 networks may transfer to ChatSpike, others may not. If you're transferring settings, you may run into problems where some access levels have changed.
This chapter is mainly focused on tweaking the channel access lists and the access levels to get what you want out of your channel with the minimum of fuss. However, playing with these settings can cause all sorts of strange problems as well as making your channel difficult to live in. For reference only, the default settings are listed below.
The majority of this chapter requires Channel Founder status, or access to the founder password. A limited subset of the functions in this chapter can be done by members of the SOP list or nicks with Acc-Change level or higher.
| Access list settings and Default Values on ChatSpike | |
|---|---|
| AutoProtect | 25 |
| AutoOp | 15 |
| AutoHalfOp | 10 |
| AUTOVOICE | 5 |
| Invite | 10 |
| AKick | 20 |
| Set | (Founder only) |
| Clear | 25 |
| Unban | 10 |
| Acc-List | 1 |
| Acc-Change | 25 |
| Memo | 10 |
| Op-Deop | 15 |
| Voice | 5 |
| HalfOp | 10 |
| Protect | 25 |
| Kick | 20 |
| Topic | 10 |
| Status | 25 |
It should be noted that the SOP / AOP / HOP / VOP lists also use this list, so any changes to these levels in your channel may affect people previously added to those lists. The general idea of the interface lists is that the nick is given the lowest level possible to gain the privileges that should be afforded to them. As an example, adding someone to the HOP list is the same as adding them to the full access list with level 10 - they can use the HalfOp command on themselves, automatically recieve it when joining or identifying, and are allowed to modify the channel topic using Topic.
The limitations for the level parameter for Version 5 of IRC Services are from -999 to 999. Negative values do have some effects which have been deprecated by the developers of the software, which are listed here for completeness. There are other ways of achieving the same result, which are preferred.
| NoOp | -1 | Stops the person from being allowed to recieve +ohv modes in this channel |
| NoJoin | -2 | Prevents the selected person from joining the channel at all (User is automatically kicked from the channel) |
SecureOps (a Set option) is preferred to NoOp because it forces all people to be explicitly named to have ops, instead of banning a select few from the list. NoJoin has been replaced by a separate AKick list as described above.
The commands to add a person to the full access list are similar to the commands used to add people to the sub-lists, with one additional parameter.
When that person next joins the channel or identifies for their nickname, they will have all required user modes set on them where required. You may have seen this when registering your channel, where ChanServ sets the mode +q on you. This mode means channel owner, to explain more thoroughly. This is also the command used to change peoples access on the list to a higher or lower value.
The other commands for modifying the access list follow the same basic principle as other lists used by services:
| /msg ChanServ access |
Lists all members on the access list with a numeric prefix. |
| /msg ChanServ access |
removes either the nick or the user in slot |
| /msg ChanServ access |
gives a count of the items on the list. |
The other half of the access list system is to modify the levels required to gain particular settings yourself. For example, you might decide to have a subset of users who can modify the topic without having halfops or ops, without leaving it open to all. To do this, pick a number less than the default setting of 10 (say, 7) and run the following command:
Now you can add people with an access level of 7 or above, and they will be allowed to use the ChanServ Topic command to modify the topic without being on the HOP list. People on the normal voice list would not be allowed to do this, as it would only give them access at level 5, and people on the HOP and higher lists would still have the required permissions. Although this seems like a trivial example, it is a pretty effective measure of the power access lists provide. In a similar vein, you could decide that everyone who enters your channel recieves voice automatically. To do this, set AutoVoice to 0, which exploits a feature of the way Services is designed. Users who do not have any higher (or lower) access level are automatically granted level 0, and so any setting at level 0 is granted to everyone in the channel. The relative positions of the items that can be set are also freely modifiable too, meaning that you can set any value to any setting you see fit. If you wish, you can (semi-effectively) ban kicking in your channel by setting AutoProtect to 0, or have a chaotic channel where everyone gets channel operator status by moving AutoOp to 0.
One thing to note is that the Set level is set to founder only by default, meaning that only the founder can modify these options. They are described above in more detail, but the options under Set are to do with ownership of the channel. I highly recommend leaving this setting alone, because you can leave yourself open to services assisted takeovers if people are allowed to modify the Founder parameter under Set. This effectively means that you no longer own your channel, and persons able to use these options can also modify the founder password to stop you regaining your channel the same way.
Comments
Send all comments regarding this document to [email protected] or go on to irc.ChatSpike.net (#ChatSpike) and look for ol. I'm usually around, and failing that the MemoServ services can take short messages.
If theres anything you don't understand about the proceedures contained in this document, grab a ChatSpike oper or helper in #ChatSpike.
Copyright Information and Licensing
Copyright (c) 2003 Oliver Rose
Permission is granted to freely copy and distribute this document. Anybody wanting to translate this document into another language is permitted, as long as the author recieves a copy under these terms.
Thanks to [Brain] and Dr_Kev for proofreading early versions for dumb mistakes.