IRC Operators Guide

Webmaster's note: This guide offers a fascinating glimpse into the "Twilight Zone" world of IRC operators, also known as IRC ops or opers. This has very little to do with channel ops or the maintenance of a chat channel. The guide is written by an oper ostensibly for other opers, but its real audience is the average user. For other help files regarding IRC ops or running servers, see the IRCd server directory. -Jolo

Note: There will be personal views in here, but I'll try to keep them to a minimum.

Contents

   I. Interacting with Users and Other Operators
  II. Using KILL and KLINE
 III. Bots and Bothunting
  IV. Cloners, Flooders, and Spoofing
   V. Why Operators (Usually) Don't Get Involved In Channel Affairs
  VI. Dealing with "How Does One Become an IRC Operator?"
 VII. IRCD and Associated Files
VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)
  IX. Server Routing and Connectivity
   X. Other Server Commands (REHASH, RESTART, and DIE)
  XI. Operator Communications (WALLOPS and OPERWALL)
 XII. Linking New Servers
XIII. Attitude and Perspective

I. Interacting With Users and Other Operators

From what I've seen, most opers look down on users, make fun of them, and ignore them. Try to avoid this ego trip side of opering. Answer private messages, unless it is someone just sending you a hate message. Opers would get a lot less crap from users if they would be a little less egotistical. Something I might suggest is that you spend an hour or two every couple of weeks helping the newbies out in #irchelp or whatever equivalent you may find.

One thing to be wary of is that users will frequently try to manipulate you into helping them takeover channels. Very rarely will a user simply report a bot without a reason. Generally this will be because a bot tookover a channel or a user is flooding them. Fairly regularly you'll get these requests from users who want someone killed off the server so they can take control of a channel. Because of this, request the channel in addition to the nickname so you can see what's going on before you kill or K-line.

Frequently, you will get requests from other operators to kill or K-line a user. Opers should be trusted unless you've had problems with someone in the past. You should always require a reason before killing or placing the K-line. If it's in the least bit questionable, add "requested by <oper>" or something similar to the K-line reason.

If you are being harassed by a user on the network, handle it like a user should handle it, not like an oper has the capability of handling it. The temptation of killing a user for flooding you is something that pretty much all of us give into on occasion, but it's generally not the right response. If we are going to expect regular users to simply /ignore flooders, then we should do the same. Though I have to admit, a user must be pretty stupid to flood an oper...

On occasion, opers have their disagreements. There is a bit of a pecking order that exists in the oper ranks, usually with hub admins and opers being more "powerful" than leaf admins and opers. It's generally not a good idea to try to win an argument with the people who are providing your connectivity to the IRC network. For that matter, it's generally not a good idea to try to win any argument at all. If you do have a serious problem with another oper, and can't resolve it directly with him/her, go to your admin about it. Your admin can then approach the issue with the other oper's admin, and if that goes nowhere, with their uplink admin. This is a quick way to make enemies, so make sure it's important to you before doing it.

II. Using KILL and KLINE

KILL nick :reason
KLINE nick :reason
KLINE username@hostmask :reason

Generally, whatever you do on your local server really is not a big deal. Different servers have different policies on using KILL and KLINE, but if you are doing global kills (killing a user on a different server), you need to make sure you understand what the IRC network's guidelines are.

Users tend to have one of two reactions to kills. Occasionally you'll get the user to cool off and realize that they need to fix whatever they are doing. More often, they will want to argue the point with you. Try to explain it to them, but if they don't seem to be willing to follow the server guidelines, just K-line them. After they get K-lined from a few servers, they'll figure it out.

You probably want to avoid K-lining users unless it's really necessary. A K-line means that you don't want that user on your server, for whatever reason. Depending on the server, K-lines may be cleared after a week or two, a few months, or maybe never. It might be wise to have a "permanent" section of K-lines, and then the rest can stay or go at anyone else's discretion. For clearing K-lines, generally it's a good idea to talk to the person who placed it before doing so. With access to ircd.conf (to remove K-lines), you can be a lot less cautious about placing them.

The best guideline for doing global kills is to ask yourself "Is this really necessary?" You can usually find an oper on the server the user is on to handle an issue for you instead. If an oper on the server won't do it, then probably they wouldn't like you killing the user off their server either.

Frequently it seems that opers are just looking for a reason to kill. Probably if you are in that mood, it would be a good time to deoper and go find something else to do for a while. Killing like that looks bad for both you and for your server.

It's a wise idea to keep logs of everything you do. I have yet to see a client that doesn't have the capability of logging. If a user or another oper challenges your kill (usually to your admin, since they typically don't have the guts to talk to you), you can provide them. You will most likely be accused of abusing your O-line, and threatened by users to get it taken away, on a regular basis. Logs are your best defense.

III. Bots and Bothunting

There are a couple of reasons why bots are frequently considered to a problem. First, they take up resources on IRC that could be used for regular client connections. The primary reason, though, is because bots are frequently used to flood and harass users. You'll want to check what your server's policies are regarding bots, but an abusive bot should never be tolerated.

Finding bots generally isn't that difficult. Many have ctcp responses that don't match what you would expect, or have bogus idle times (in their ctcp finger response). Also, there are a couple of good portscanners that can help you check hosts for bots (eggdrop bots usually listen on a port for incoming telnet connections).

You probably aren't going to find all the bots being run by hardcore botrunners. They generally find out quickly about whatever new bothunting methods we come up with and spread the word. With these, your best bet is to wait until someone complains about it, and then monitor its behavior.

Here is a short description of a few of the bots out there, and a couple of tips for finding them:

• eggdrop - this is the most common bot that you'll run into. Typically you'll see "/msg botnick hello" in the gecos field (the description line in the whois information) if the bot is poorly configured. Additionally, by default, these bots PRIVMSG #lamest for invite/ops. They also join #botcentral by default.
• johbot - these bots PRIVMSG blahb1ah on a regular basis. If you change your nickname to that, you can sit and wait for them to find you. Additionally, if you enter the channel a suspected johbot is in, and do a fake netsplit quit (/quit irc.blah.com irc.something.net), the johbot will automatically change its nickname.
• combot - these are a comstud creation. I have never found one myself, which either means there aren't many around, or they just hide really well. I've heard that doing a /ctcp botnick source will generate a reply with "Combot" followed by the version.

IV. Cloners, Flooders, and Spoofing

Generally, cloning itself is not all that bad (just taking up connections). Frequently when you see clones, however, they are being used to flood users or takeover channels.

The best approach to take with clones is to kill them, and see if they return. If you do this a couple of times, and the user insists on keeping them on, it's time for a K-line. Unless a user is consistently a problem, clone K-lines should be relatively temporary (a few weeks is sufficient).

You'll see two forms of flooding on IRC. The first is CTCP flooding, which attempts to get a user to flood the server with CTCP responses, tripping the server's flood protection, and terminating the user with the message "Excess Flood". Many bot networks ("fludnets") use this type of flood. Flood protection scripts may prevent this from being very effective, but the real problem is the impact on the network. If 20 bots flood a user for 10 seconds, sending five 100 byte CTCP requests per second, that is 20 * 100 * 5 = 10k/sec, or 100k of data total over the 10 seconds. When a network that is maintaining 30000 users, this sort of activity is not at all acceptable.

The second type of flooding, which is not related to IRC (but is frequently the result of conflicts on IRC), is ICMP flooding. This is usually done from a reasonably fast link (ISDN or higher) and consists of flooding a user or server with ICMP packets (such as ping). This is considered a "Denial Of Service" attack, and is against the law.

There are many flooding scripts out there right now, and a couple of these have supposedly "random" nicknames they use for CTCP flooding. A trick to use is to set a couple of those nicks in your notify. Some flooding scripts also have the clones join specific channels (e.g. #srfloodclones).

DNS spoofing is a relatively new hit these days on IRC. You'll generally find spoofs one of two ways - you're watching the connections (usermode +c) and an unusual hostmask appears, or a user reports one. The first thing to do is to get the user's IP address (/stats L nick), and check to see if the DNS lookup matches the IP address. If it doesn't, you know you have a spoof. With this information, you can KILL the spoof, and when it reconnects, see where the real host is and issue a K-line (which won't stop them from spoofing again, but will prevent them from signing on *without* spoofing). Some servers have the capability of D-lines, which allow you to ban by ip mask. A D-line will prevent the client from connecting at all, regardless of whether they try DNS spoofing or not. If the server supports the DLINE command, you can do /dline ipmask :reason.

V. Why Operators (Usually) Don't Get Involved In Channel Affairs

In practice, you'll find opers defend their own channels, and turn their backs on others. It's a little pathetic, but after you get harassed enough by users saying "why are you getting involved? I thought opers weren't supposed to get involved in channel affairs" you'll start to understand the cynicism.

VI. Dealing with "How Does One Become an IRC Operator?"

For example, use an alias like "Becoming an IRC Operator requires not only a strong working knowledge of IRC and this IRC network, but also a working relationship with hub admins and other opers. Opers are selected when there is a need, and never given based on who is asking for it."

The thing to remember is that there are always going to be more people that want to be an operator than there are openings. If you really want to help the network, the best way to do it is by answering new user questions on channels like #irchelp and #help.

VII. IRCD and Associated Files

The installed file structure varies from server to server, but you should have at least these two primary files:

	ircd			the IRC server daemon (main program)
	ircd.conf		the server configuration file

A:Company/Institute Name:Server Description:Admin Name <email@address.com>

This configures the administrative functionality of the server, which is returned when a user does /admin on your server. The fields are completely up to the administrator of the server, but what I put above seems fairly standard. This is a mandatory field.

B:hostmask::nick::

This line indicates a permitted bot. The server has built-in bot checking for certain known instances of bots, and will refuse the connection if it detects one. If the bot has this line in the config file, the server will not refuse the connection.

C:server hostname:password:server name:port:connection class
N:server hostname:password:server name:hostmask:connection class

C/N-lines are connections to other servers. The C-line defines what servers your server can connect to, and the N-line defines what servers your server allows incoming connections from. I have never seen one without the other, and according to the sample ircd.conf, they must be used in pairs. The server hostname, password, and servername are fairly self explanatory. The port is used to identify which port your server will try to connect to automatically; if the port field is blank, your server will not automatically attempt to connect to that server. I have never seen the hostmask used (nor do I really understand what it does). The connection class is numeric, and defined in the Y-lines.

D:ipmask:reason:

This line is used to ban a block of IP addresses. If a system administrator has control over several domains, he/she may attempt to avoid bans by changing the reverse DNS lookup on the host (a perfect example of this is smartec.com, who has several domains and several machines all on one Class C). With a D:line, you can ban 205.230.73.* (smartec) and nobody from that address space can connect, regardless of DNS lookup.

E:hostmask::username

The E-line protects certain users from server bans (K-lines). Generally operators use them to protect themselves from accidental K-lines, but in some cases, a server run by an ISP will also use them to protect their customers.

H:remote servers permitted::hub server

This defines a hub server, which is a server that may have other servers connected behind it. The "remote servers permitted" is usually "*" or may have a hostmask to limit the remote connected servers to within that mask.

I:address mask:password:domain mask::connection class

I-lines define what clients are allowed to connect to your server. Additionally, they define what connection class (defined by Y-lines) the client is placed in. The password is usually left blank.

K:hostmask:time:username

Most people already know what a K-line is, but for the record, it's simply a ban from the server. I have never seen a K:line with a time field, but it allows you to define what times a client is allowed on the server. Generally, K-lines are added with the KLINE command on the server, and the reason is stored as a comment in the config file.

L:restricted servers::connected server:depth

This is used to identify leaf depth behind a server. The restricted servers field is a hostmask for what servers to not allow behind the connected server (usually this is blank). The depth is what depth of servers may be connected behind it.

M:hostname:*:server description:default port

This line sets the basic information for your server. The fields are pretty self-explanatory. This is a mandatory field.

N: <see C:>

O:ident@hostname:password:nickname:connection class
o:ident@hostname:password:nickname:connection class

These lines define the operators on the server. The lower case o-line identifies a local operator, who can do local server KILLs and KLINE, as well as SQUIT and CONNECT their server from/to an uplink server. The upper case O-line is a global operator, who can additionally do global KILLs (killing users off other servers) and SQUIT and CONNECT any server on the network. The connection class is as specified in the Y-lines.

P:hostmask:::port

These are the ports that your server listens for connections on (in addition to the default port set in the M-line). The hostmask is an optional field that allows you to specify which users may connect to that port.

Q::reason:server

The Q-line specifies a server that will not be allowed to link to the network at all (all servers must have identical Q-lines according to the sample config file). I have never seen this used.

R:hostmask:program path:username

Allows you to process access control through an external program (provided by the server admin). Whenever a client connects, the server calls this external program with the user information. The program then responds based on whether or not the user should be granted access to the server. I've never seen this used either, and is probably impractical for any server with a large client base.

Y:class id:ping frequency:connect frequency:max connections:max sendq

The Y-line defines a connection class. The class id is a number that identifies the class, and is used in I-lines and C/N-lines to identify which Y-line to use. The ping frequency is the time (in seconds) between ping requests (to verify that the connection is still alive). Connect frequency is the time between automatic connection attempts for server connections (should be zero for client connection classes). Max connections is self explanatory. The "sendq" is the amount of data (in bytes) that is allowed to be pending going out to a connection in that class before the server will close it (with a message such as "Sendq exceeded").
On the 2.9.x versions of ircd, the connect frequency is replaced with an identifier to handle cloning. If it is a positive number, it identifies how many clients can connect from the same hostmask. If negative, it identifies how many clients can connect from the same username@hostmask.

VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)

TRACE [server|nick]

The TRACE command is used to trace the path from your current server to the specified server or user.

When the destination is a server, TRACE will also return information about current server and operator connections, incoming connections (with negative class numbers), and the number of users in each class. The oper connections contain the connection class, the nickname, and user@hostmask for the oper. For server connections, it shows the connection class, the number of servers behind it (followed by "S"), the number of clients on and behind it (followed by "C"), the server name, and what was responsible for connecting it.

When the destination is a user, TRACE shows the connection class, nickname and user@hostmask for that user.

STATS [letter]

The STATS command returns server information. These tend to vary by server version, and are sometimes case sensitive. Here are a few that I know or use regularly:

	?	Server connection statistics
	b	B-lines
	c	C/N-lines
	d	D-lines
	e	E-lines
	h	H/L-lines
	i	I-lines
	k	K-lines
	l	Data transfer statistics by connection
		The numeric fields are as follows:
			sendQ (outgoing message queue)
			sendM (protocol messages sent)
			sendK (total kilobytes sent)
			receiveM (protocol messages received)
			receiveK (total kilobytes received)
			time in seconds since the connection was created
	L	Same as STATS l, except shows IP address instead of host
	m	Command statistics
	o	O/o-lines
	p	Current opers online
	t	General server statistics
	u	Server uptime
	v	Server link information
	y	Y-lines
	z	More server statistics

If you are not currently an oper, I don't recommend going through and testing these all at once. Multiple STATS requests are usually viewed as a threat to the server (some people have been known to flood a server with STATS requests to fill up the server's sendq and cause network splits).

LINKS [server mask]

This shows the structure of the irc network, and is a bit useless if you don't have a script or client that formats it for you. Each line contains the server name, its uplink name, the number of hops from your server to the server, and the server description.

HTM

The HTM command is used to view and set the high-transfer mode threshold. Additionally, it shows the incoming data rate, which is useful when monitoring how you are doing when relinking to the network.

IX. Server Routing and Connectivity

For my description, let's assume a network that looks something like this:

		A-----B----C----D
		      |         |
		E-----F         G----H
		|     |         |
		I     J----K    L----M

211 irc.d.com[123.231.132.213] 1621588 9780 559 469469 24111 5862

The sendq is the first number after the IP address, or 1621588 in this case. If we do a STATS y on server C (/stats y irc.c.com), we can see what the max sendq allowed is. Look for the connection class with something aside from 0 in the connect frequency field (600 in this case):

218 Y:0:120:600:10:4000000

So if that number reaches 4000000, server C will disconnect server D, and you'll see everyone on the other side quit with the message "*** Quit: nick (irc.c.com irc.d.com)" or whatever.

Now, if you were on server L, you would do STATS l on server D (/stats l irc.d.com) and look for the entry for server C. In this scenerio, you might see

211 irc.c.com[132.213.123.231] 142 8841 512 485915 21058 1234

Since the sendq going from irc.d.com to irc.c.com is only 142 bytes, it looks like a one-way lag situation (server irc.d.com is having trouble receiving data from irc.c.com).

Let's say you continue to monitor the sendq from irc.d.com to irc.c.com (with /stats l irc.d.com from your position on server A), and it rises from the previous 1621588 bytes to 3140419 bytes. You could wait it out and see if it splits or catches back up, but we'll decide to reroute it now instead.

Before you do anything, you have your clone over on server L do a STATS c on server D (/stats c irc.d.com) to see where it can reconnect to. Let's say an alernative link is server F. You now have a place to put it, but then you need to find a port. From your client on server L, you do a STATS l on server D (/stats l irc.d.com) and look at what ports it has open. Here's a couple of STATS l response lines that we are interested in:

	211 irc.d.com  0 30844455 1978134 15372958 794195 156641 156641 -
	211 irc.d.com[@*@*.6665]  0 702234 48662 118794 5963 156641 156641 -
	211 irc.d.com[@*@*.6666]  0 1750847 130878 547336 22204 156641 156641 -
	211 irc.d.com[@*@*.6668]  0 568644 38618 100102 4626 156641 156641 -
	211 irc.d.com[@*@*.6669]  0 701079 48973 121065 5271 156641 156641 -

Now, we want to disconnect server D from server C, and then tell server F to connect to server D on port 6665. We will do all this from server A. We start with the SQUIT command, which has the following format:

SQUIT server :reason

So we do this:

/squit irc.d.com :reroute

At this point, it's a good idea to wait a minute for the servers to process the change, and then we can relink using CONNECT, with the following format:

CONNECT server port link_server

So we do this:

/connect irc.d.com 6665 irc.f.com

You can monitor the reconnect status with STATS l on irc.f.com, though in most cases, a good connect will take less than a minute.

If you are opering from a leaf server (like I do now), then you will generally only SQUIT and CONNECT locally to your uplink. So you have the following network:

	A----B----C
	          |
	     D----E

	/squit irc.b.com :reroute
	/connect irc.d.com [port]

One last issue regarding server connectivity is "juping". When a server is having problems or has been compromised, and an admin for the server is not available, the server can be prevented from relinking by putting a fake server connection to the network in its place. When the server attempts to link, the network sees it as already being connected and rejects the server connection.

X. Other Server Commands (REHASH, RESTART, and DIE)

REHASH

The REHASH command simply tells the server to reload its configuration file. This must be done for changes to ircd.conf to take effect.

RESTART

This command completely shuts down the server and restarts it. All connections will be closed (including yours).

DIE

This shuts the server down. Generally this is done when restarting the system the server is running on.

XI. Operator Communications (WALLOPS and OPERWALL)

The format for both commands are:

WALLOPS :message text
OPERWALL :message text

XII. Linking New Servers

These are some of the issues that face new servers:

Link Speed

The minimum link speed to get a link is usually T1 (1.544 mbps) to a major backbone provider. Even this is often considered inadequate.

Server Requirements

The server must be running some flavor of Unix. Unix was designed around networking and generally can handle far more than other operating systems can. Whether this is true or not isn't the issue - it's completely based on the opinions of existing hub admins (which I happen to agree with on this issue).

The ircd process generally can take between 30 and 60 megs of memory when running on EFnet, so 64 megs is probably the minimum there. No other real processes should be running on the machine.

Existing IRC Users

To get a link, you should probably be averaging about 30 users at any given time from your domain. This can vary, and may not be a serious requirement if you have excellent connectivity.

Operators

Your list of potential operators can affect your ability to link. If you have known abusers as operators on your server, you probably won't get a link.

Politics

What it all really comes down to is whether or not you know and are liked by the hub admins. If they don't like you, I'd recommend pursuing golf as a hobby instead. :)

XIII. Attitude and Perspective

Aaron Brinton
aaronb@telanis.com
EFnet Operator (irc.ionet.net, irc.uci.edu)

Special thanks to Ruth Mullen (hershey@ircnet.org) for many suggestions and saving me from some grossly embarrassing grammatical mistakes. :)

Copyright © 1996,1997 Joseph Lo and many others.