1. Servers - How IRC works

1.1. Servers and clients

IRC stands for Internet Relay Chat. IRC is a collection of networked servers, to which so-called "clients" can connect and then interact with other clients connected to the same or other IRC servers. Every "person" you see on IRC is a client of some server. Typically, servers run 24 hours a day, 7 days a week, waiting for clients to connect. Clients, on the other hand, typically only run when a user wishes to use IRC, although there are exceptions to this rule, specifically bots. When you type /server irc-2.mit.edu, you are opening a connection to the machine irc-2.mit.edu. (Typically, though not always, the client connects to the server on port 6667. When you type /server irc-2.mit.edu, your client assumes this to be the case. If you actually wanted to connect to port 6665, you can type: /server irc-2.mit.edu 6665.) irc-2.mit.edu, in turn, is running a server program which is connected to a large number of other machines running server programs (usually just called servers). It relays what you type to the other servers, and it relays what users on those other servers type to you. Each server keeps a list of what is going on in each channel its users are on, and when a user on any server changes anything on that list, that user's server notifies all the other servers of the change.

1.2. How servers link and why they split

Servers link up via the Internet, and send lots of traffic out to each other. When net traffic gets heavy (not just IRC traffic, but all net traffic) then the links get overloaded and break. This is called a "netsplit." When someone netsplits, it looks like this:

This indicates that the connection between eff.org and dewey.cc.utexas.edu is the one that broke down, and that you are on the eff.org side of the netsplit, while Thoth was on the dewey.cc.utexas.edu side. This does NOT mean either that Thoth is necessarily on dewey or that you are necessarily on eff.org; just that Thoth was on that side of the split and you were on this side. When a link between your server and another server breaks, then anything done on your server won't be relayed to that server, and anything done on that server won't get back to you -- at least not until the net rejoins.

1.3. Things that can happen when a server splits

When a server splits it no longer knows what the other servers have been up to, and other servers don't know what has happened to it while it was split. So, the split server could have new ops that were made while it was split, or new bans, or new users. When the server rejoins, it updates everyone on what has been going on, which is why you will see something like:

That was the server dewey.cc.utexas.edu "synching" its information with everyone else's and telling everyone it had a new op. Sometimes, the server updates don't work, and servers persist in seeing their own view of reality. For example, picture this:

A server, in this case dewey, opped Thoth. Then SilverOz immediately deopped him. SilverOz most likely deopped him before her server had a chance to tell Thoth's server that SilverOz was an op. If Thoth also tried to deop SilverOz, from Thoth's perspective, the whole incident looked very different:

So, the eff.org side sees SilverOz as opped and Thoth as deopped; the dewey side sees the exact reverse. The dewey side will now ignore anything that SilverOz does that requires ops, and the eff.org side will likewise ignore anything Thoth does that requires ops. The message you'll receive will look like this:

SilverOz would not even see the ban or the kick, since her server doesn't acknowledge Thoth's ops as legitimate. Thus, people who are connected to one server may see bans and ops that people connected to another server can't, even though all those people can see each other and are talking. When that happens the server is said to be "desynched."

Note here that SilverOz WOULD STILL BE ABLE TO SEE EVERYTHING THOTH SAYS ON CHANNEL, EVEN THOUGH THOTH THINKS HE KICKED HER OFF. Because he kicked her off, whenever she tries to send text to channel, she will get a message that says:

Since Thoth's server doesn't think she's on the channel, it won't relay what she says to Thoth. But, since SilverOz's server thinks she's on the channel, it will relay whatever it sees Thoth saying to her. Note also that SilverOz can leave the channel on her side and rejoin. From Thoth's perspective, she will join the channel even though he banned her, because her server will inform all other servers that she joined. Thoth's server will simply accept that as a fact without checking the ban list. For more consequences of splitting, see 3. How the hackers take channels (and what to do about it)

2. A Guide to the Mode Command

2.1. What are modes?

Modes are the parameters of a channel, they define what can and can't be done. Note that both users and channels can have modes, but the effects of a particular mode (say +i) are different. This document deals with channel modes only, for more information, see the files listed at the end of this document.

2.2. The main channel modes

There are 7 main channel modes. Which ones you set your channel to will depend on what you want to do. You can set modes singly or in clumps:

/mode #channelname +nt

is the same as

/mode #channelname +n
/mode #channelname +t

2.2.1. +n

+n means "no notices". this stops people or bots sending notices or msgs to the channel from outside. Your channel should *always* be set +n, to stop low-lifes from flooding it.

2.2.2. +t

+t means "topic". If this is set, then only operators can change the topic. You don't have to set this, but in my experience if you don't then you will get flooded with topic changes. No idea why, it just seems to happen that way.

2.2.3. +i

+i means "invite only". Anyone who wants to join the channel has to be invited by a channel op. Nice if you don't want drop-ins or as part of a defence against people actively trying to take the channel, but otherwise annoying.

2.2.4. +p

+p means "private". If your channel is set +p. then if someone does a /whois on anyone on that channel, the fact they are on that channel will not be revealed. However, it will be obvious that they are on *some* channel. The /whois will like like this (provided you are not on the channel yourself):

NOTE: A channel cannot be both +p and +s

2.2.5. +s

+s means "secret". If your channel is secret, then no answer will be returned if someone does a /names #channel. (Of course if they are *on* the channel when they do this they will see all the people on it. A /whois of someone on a secret channel will look like this (provided you are not on the channel yourself):

NOTE: A channel cannot be both +p and +s

2.2.6. +k

A channel set +k requires a keyword to enter. On EFnet (the "main" IRC net) this keyword can contain unprintable chars. On UnderNet, only printable chars count. To set the keyword for channel #silveroz to mykey:

/mode #silveroz +k mykey

You also need the key to remove the mode... If you know it,
/mode #channelname -k mykey
if you don't, see below.

2.2.7. +m

If you set the channel +m, then only operators or people who an operator has set +v can talk on channel. This is a useful way of dealing with an attack by floodbots.

2.2.8 +o

The +o mode is set or unset for particular users. Making a user +o gives the user operator status on the channel. Making a user -o removes operator status.

2.2.9 +v

The +v mode simply gives someone on a +m channel permission to send text to the channel, even if he or she is not an op. (All ops automatically have permission to speak.)

2.2.10 +l

This sets a limit on the number of people that can join the channel. This mode does not really guarantee that no more than the set number of people will be on channel. For instance, setting this mode does not kick anyone off if the channel is over the limit. And, people who split in totally ignore the +l limitation (just like they ignore every other channel mode limitation.

2.2.11 +b

This mode bans any user who matches from joining. This is covered in-depth in section 2.6.

2.3. Clearing channel modes

Modes are normally set and cleared by the mode command as follows:

/mode #channelname -n /mode #channelname -nt

You can combine mode commands too. Supposing the channel was currently +i +n +t (usually written as +int). You can remove the +i by

/mode #channelname -i

But supposing you want it to be -i but +s?

/mode #channelname -i+s

2.4. Opping and de-opping

To give someone ops, you use the mode command again:

/mode #channelname +o SilverOz

To de-op them:

/mode #channelname* -o SilverOz

You can op or de-op up to 3 people at once:

/mode #channelname +ooo SilverOz Tangent Agatha
/mode #channelname -ooo SilverOz Tangent Agatha

note that the number of "o"s has to match the number of people.

2.5. Kicking

To kick someone off the channel, you use the /kick command:

/kick #channelname SilverOz

You can add a comment the person will see when they are ejected:

/kick #channelname SilverOz Good bye and good riddance!

You can only kick one person at a time.This is one of those commands it is nice to have an alias for -- see the section on scripts for how to write an alias. Also note that it's often adviseable to ban a user before you kick them -- that way they don't jump back on channel during the interval before the ban takes effect. See section 2.6.1.5 for further details.

When banning, the nick and user and host info are written like this:

So, anything to the right of the ! is a nick, anything between the ! and the @ is the user portion (also called account, or account name) and anything to the right of the @ is the host. You can use wildcards in bans, special characters that stand in for a character or group of chars.

So "S?lverOz" will match "SilverOz" and "SolverOz" and "SklverOz" but not "SiilverOz." and "*Oz" will match "SilverOz" and "AgOz" and "SilverOOz" but not "Silver" or "SilverOzz." Also, "*.hacker.com" will match "bozo.hacker.com" and "luser.hacker.com" but not "hacker.com" itself. Note that some users can change their account name as easily as the rest of us change our nicks. This means you will have to ban their entire host, or possibly their entire domain, to keep them off the channel.

2.6.1. Types of bans and when to use them

There are several kinds of bans, each one useful for a different purpose, although there are one or two (notably "screwbans" the ones with lots of single ? wild cards in them) which seem to be completely useless.

2.6.1.1. Nick ban

The correct format for a nick ban is:

/mode #channelname +b nick!*@*

This bans anyone with the nick "nick." E.g. /mode #channelname +b SilverOz!*@* will ban anyone with the nick SilverOz from the channel. Of course if they change their nick, then they can slide right past the ban. This ban is pretty useless against people, but can be used to get rid of bots, who usually don't change their nicks. (Some bots do, though. Incidentally, on EFnet, you can see the bans on any channel, whether you are on the channel or not, by typing /mode #channelname channelname b.) It can also be used to get rid of an idle user you have kicked who has auto-rejoin set on, and immediately comes back on channel. In that case, ban them, then unban about 5 mins later.

2.6.1.2. User@host ban

The correct format for a user@host ban is as follows:

This is your standard everyday ban. It bans all nicks (*! means "all nicks") from their username (*user* means their username, plus the * at the beginning takes care of the ~ mark you sometimes see, and the * at the end insures that the username you provide "fits" into the space -- no more than nine characters will fit), from all machines in their domain. E.g., to ban SilverOz who is zjohnsto@scu.edu.au you would type:

To ban Luser who is lame@mm.elcheepo.edu you would type:

Note that for the non-US address (.au means Australia) you leave 3 parts of the host name, for the US one, you only leave 2. Most scripts would write the ban as:

which works OK unless you get someone with a 2 part hostname, e.g., luser has another account, joe@hacker.com, with access to joe@phreak.hacker.com and joe@hacker.com. /mode #channelname!*joe*@*.hacker.com will ban the first account, but not the second.

2.6.1.3. Site ban

The format for an effective site ban is as follows:

/mode #channelname +b *!*@*host.suffix

This bans everyone from a particular domain or machine, no matter who they are, or what their nick. For example, if you wanted to ban SilverOz and everyone from SCU, you would type:

/mode #channelname +b *!*@*scu.edu.au

Then it wouldn't matter who the person was, if they were on an scu machine, they will be banned. You can also ban users from particular machines, so if you wanted to ban users from alsvid.scu.edu.au but not angus.scu.edu.au, you could type

/mode #channelname +b *!*@alsvid.scu.edu.au

2.6.1.4. Banning by IP address

Some servers don't give the machine name when you do a whois, they give a series of numbers, which is the "IP address". A numeric address is actually the person's "IP" address, and sometimes simply banning the whole IP address is good enough. E.g.:

/mode #channelname +b *!*zjohnsto*@203.2.20.1

If the person being banned actually has access to other hosts on that network, or can change to another IP address that they own, it gets more complex. There are three basic types addresses that you can get when you register a network: Class A, Class B, and Class C. A Class C network is a small network - no more than 255 hosts on it, and is the most common you should see. In a class C network address only the last number will change. If I knew SilverOz was on a class C network, I could do a site ban on her with:

/mode #channelname +b *!*zjohnsto@203.2.20.*

A class B network is larger, up to 65535 hosts, and the last two components of the address can differ. For a class B you would use

/mode #channelname +b *!*zjohnsto@203.2.*

Class A is 16777215 hosts and all three of the final compoentents can change. There are only 255 class A networks - all owned by large corporations. Many networks, especially the larger ones, are subnetted, which means that even if the hacker is on a large network, the piece they are on can probably be banned simply by wildcarding the last part of the address. Ok - cut to the chase.

You can ban by /mode #channelname +b *!*zjohnsto*@203.2.20* but that will ban people from 203.2.202.4 for example, quite likely a completely different domain. The moral: include the ending period when banning by IP address. Now you know more than you ever wanted to about IP network addressing.

2.6.1.5 Efficiency

It's possible and desirable to make your kicks and bans more efficient. For instance, you should always deop a user before you ban him or her. Why? Because if you don't, the user could deop you or kick you first. This task can be made simpler and more efficient by combining modes. For example, to remove Thoth from the channel, you could do the following:

The mode change command effectively de-opped Thoth first and then instantaneously banned him.

2.6.2. Clearing bans

To check what bans are on the channel, type

/mode #channelname b

(NOTE: This works regardless of whether you are on or off channel, but of course if you are off channel you have to use the channel name, /mode #channelname b.) To clear old bans you have to remove them *exactly* as they were written - a terminal with cut and paste is invaluable for this. If you make a mistake, the system won't warn you, it will tell you the ban is removed, even when it hasn't been. You must get the ban exactly right. To clear a ban:

/mode #channelname -b

e.g.
to clear the ban *!*zjohnsto*@*scu.edu.au
/mode #channelname -b *!*zjohnsto*@*scu.edu.au

2.6.3. Why a ban may not work

Sometimes you ban someone, and they come right back onto the channel anyway. This could be that you didn't ban them properly in the first place! But if the ban looks OK, then there may be something else....

2.6.3.1. Too many bans

A channel can only hold 20 bans at a time. If you try and ban someone and there are already 20 bans up, then you won't get a mode changed message, you won't get anything at all. If that happens, then clear one or more bans, and try again.

2.6.3.2. Similar bans

If there is already a ban in place that is similar to the one you are trying to place, then yours won't work. Remove the bad or redundant ban, and try again. How similar is similar, you ask? Well, a ban is deemed "too similar" if the nickname portion or the user and host portion of the ban match the parameters of any other already existing ban.

2.6.3.3. Desynched servers

This is a nasty problem. If a server becomes desynched, then a hacker can get on the channel on that server because the ban you just placed won't be in the split server's memory. Thus, the hacker can leave and rejoin at will, and to you, it looks like the hacker joined, ban or no ban. See Section 1.3 What happens when a server splits.

2.6.2.4 Split servers

When a split server rejoins, all the people on the split server join the channel on the other server, period. Bans do not matter. You can kick them off once they have joined, of course, but bear in mind that this is not always a good idea, necessarily, especially during a takeover attempt, because they will still be able to see what you say, but you won't see what they are saying! By the way, there is no announcement that the person that just joined did so because of a split -- it looks exactly like a regular join.

3. How hackers take channels (and what to do about it)

Time for a little soapbox sermon, on IRC takeovers and counter-strategy. IRC channel takeovers happen. Why? Bored dweebs with way too much free time, looking for "thrills." People who feel the current channel ops have insulted or annoyed them. People just seeing if they can. Your options? Basically, you can try one of three options:

1. Appease them.
2. Ignore them.
3. Defend the channel.

The problem with appeasing channel hackers if that this often leads them to believe that hacking or threatening to hack your channel is a good way to intimidate or manipulate you. Experience shows that appeasing a channel hacker frequently results in continued harassment and continued hacking. Basically, if you want to try appeasement, you should make sure the hacker does not go away with the idea that his or her hacking was worth it. On the other hand, this may defeat the idea of appeasement.

Ignoring the hackers is a valid option, particularly in the case of small channels. If you don't need the hassle of trying to take back a channel -- and it's a pain in the ass no matter how you look at it -- then your best bet may be to simply make a new channel and wait the hacker out. Most hackers don't really care about the topic of the channel, have no desire to maintain a channel, and will leave after a day or a week or a month of causing trouble. At any rate, the idea here is to not fan the flames, to let things die by neglect. Completely /ignoring the hacker is probably a good move.

The problem with ignoring the attackers is that it's an inconvenience and the hackers know it's an inconvenience. They are doing it to irritate and manipulate you and your channel. If you let them do it once, they may well do it again and again. In my view, the only way ignoring a hacker will really work in the long run is if you really *don't* care about what channel you are on, if you and all your users can all go from #ductape to #ductape1 and be just as happy. If you really do care, ignoring won't do for long.

The third option is to try and defend your channel. Here are some very basic defences. If you really want to fight hard, you will need good IRC skills, programming ability, good bots, and a hell of a lot of time.

Some general rules:
* There are no absolute rules. Every rule allows for a commonsense exception. Use your judgement -- but on the other hand, be very careful. Think about what you are doing.

* Take your time and do things right -- but take your time with haste. :)

* Don't op someone unless you are sure they are who you think they are. Never op someone solely based on their user@host.

* Always de-op people who come in from splits with ops. You can always re-op them later.

* If you think the channel is under real heavy attack, then make it +i. Make sure all ops are mode +i themselves (/umode +i) and then get them to change nicks. Also, ban all accounts or hosts that you think are dangerous. This will prevent everyone except people who slide in from a split from figuring out who the ops are on channel (unless there's a spy on channel). Why all the effort to prevent people from finding out the nicks of the ops? To prevent nick collidions (see section 3.2).

Of course, making the channel +i means that no one can join the channel unless they know the alternate nicks of the ops, so it will disrupt normal life quite a lot.

3.1. Op/friend impersonation

What it is: One of the simplest ways is to take the nick of someone you know is a usual channel op. Then you join, and pretend to be that person. You ask for ops, saying its a borrowed account, or you just wait for someone to op you.

What to do about it: Yes, it seems incredible, but *lots* of people will op on nick alone. The moral is *always* do a /whois before opping someone. Most scripts like Toolbox Axis and (ugh) Phoenix op on user@host. Beware of using a script to auto-op people as usernames can be faked.

3.2. Nick colliding

What it is: If you are using the nick Fred, and someone on a split server chooses that nick, when the servers rejoin, you are both always automatically /killed (kicked off of IRC) by each other's server. Hackers are OK with this, because they make sure the thing that is taking your nick is just a bot. They themselves are not killed because you were not expecting them and did not put up a bot that used their nickname. Obviously, when you were killed, you lost ops on whatever channel you were on, so you were no longer in a position to defend the channel. If the nick collider successfully collides every op on the channel, then nobody is around to deop him when he gets opped by the server. Since he's the only op, he wins...sort of.

Why sort of? Well, this kind of thing always happens when the net is unstable. Thus, he may successfully collide everyone, only to split off again. If you can regain ops during that interval and change your nick, you have a chance to avoid getting collided again. The smarter hackers, though, often have spies -- either their own clients or someone else's -- sitting on the channel on your side of the split, telling the hacker who the ops are.

What to do about it:
1. Spread ops around to all reliable people. Make the hacker spend time creating more bots.
2. Make yourself +i. Don't make it easy for the hacker to display the ops' nicknames.
3. Always, always, deop server ops. They can be redone; the hacker becoming the only op on channel is not so easily undone.
4. Change your nickname often.
5. Kick off all suspicious accounts. Make the channel +i if necessary.
6. Put a client on the split server, if possible, or at least on the same side of the split as the split server. Have that client join the channel on that side and keep you informed about what is going on there. It's better if it's an account the hacker won't know is yours.
7. Create bots to nick collide the hacker. Bring a ton of bots on the channel and op them all.
8. Bear in mind: IF YOU KICK THE HACKER WITH THE MISTAKEN IDEA THAT HE WILL THEN NOT SEE WHAT YOU SAY OR THE NICKS YOU GIVE YOUR BOTS AND YOURSELF, THINK AGAIN! Not only will this not have that effect, but you will not even be able to tell when he splits off again, at least not easily. The only time that your nick matters is when there is a split, so change your nick and your bots' nicks AFTER the hacker splits off again.
9. Be creative and think. A good hacker already knows you will do these things. Try to think like the hacker thinks. How would YOU go about taking over a channel?
10. Be persistent. If you hang in there long enough, eventually you will get the channel back. In the meantime, postcards, letters, e-mail and phone calls to the hacker's service provider, the hacker's servers and any other method you can think of to make the hacker's life difficult are reasonable tools to use. You didn't ask for the aggravation, and you are not bound by the hacker's "rules of the game."

3.3. split server

What it is: A server may split and no one from your channel is on that server. If someone joins it while the server is split, they get ops (because as far as that server is concerned, no one was there). When the server rejoins, it will tell all the other server those people have ops.

What to do about it:
Always de-op people who come in opped from split servers. you can always op them later. If you are serious about your channel, you should run a bot that does this, else you can get scripts that can do it. If someone comes in opped, you de-op them, they leave the channel, and a few minutes later, back they are again, opped...ban them. Once is accident, twice is hacking. To get opped twice like that, they would have either had to deop you on their server, which is bad, or they would have had to leave the channel and rejoin again during the split -- a lot of effort to go to, and for not much good purpose, except to grab ops. [Of course if you know them, use discretion... maybe /msg them see what is going on.]

3.4. desynched server

What it is: [See the section on servers] This basically boils down to you having ops on one half of IRC, and the hackers having ops on the other half (or nobody having ops on the other half).

What to do about it: The solution is simple (in theory): If you have ops on your side, make the channel +i. Then kick everyone off. Finally, leave and come back (come back QUICKLY!). You will be reopped on all servers, because your server will perceive you as being the only person on the channel (everyone else was kicked off, as far as your server is concerned). The side on which you were not opped will see:

*** Thoth has left channel #bdsm
*** Thoth (~thoth@disco.intercon.com) has joined channel #bdsm
*** Mode change "+o Thoth" on channel #bdsm by dewey.cc.utexa