A Channel Security Concept



In the attack section I showed and explained various ways to DoS or takeover a channel. This document now has been written to show and explain you a concept to secure a channel on IrcNET. Some things maybe different or not needed on other networks, but I guess every channel security team can take something useful from this page.

Index

  1. General Information
    1. Tasks And Services In A Channel
    2. Client Count
    3. Eggdrop's Role In The Model
    4. Eggdrop - The Only Solution?
    5. Exempts/Invites for Important People
  2. Eggdrop Botnet
    1. Topology And Hubs
    2. Sharing / Eggdrop Account Management
  3. Stability Of Client Presence In Channel
    1. Choosing Shells For Clients
    2. Choosing Servers For Clients
    3. Eggdrop Versions
  4. Security In Practice
    1. Regulars Only Channel
    2. Country / Local Channel
    3. Auxiliaries Concept (UPDATED - 03.07.2000)
    4. Limit Concept
    5. Ban Management (NEW - 03.07.2000)
  5. Social Group / Takeover Problem





I. General Information

This section covers the basics about channel security using client connections such as bots, bouncers or screens. You can also use mIRC clients with customized scripts for channel protection, but due to the nature of Windows I don't advise that..


a) Tasks and Services in a Channel

 Overlooking the various needs of an average channel I see three major tasks which has to be performed:
  • Op Control - give and take ops, care about who is op
    • Give op
    • Care about op (bitch mode)
  • Security - deal about netsplit joins, ctcp floods, etc.
    • Care about floods (join, ctcp, etc.)
    • Deal with netsplit takeovers
    • Set b/e/I modes
  • Public Relations
    • Monitor public chatter (text flood, unwanted colours, etc.)
    • Serve information (i.e. !seen)
    • Entertain (statistic scripts, games)
    • Provide services (i.e. notes)
These three tasks require different configurations on flood, trigger and other behaviour. It's impossible to achieve all the three goals mentioned above with just one or two clients. To fulfil the requested features, you need at last three clients with respectively different setups. Such a load balancing, task share configuration looks this way in practice:

Scenario: Op-Bot, Public-Bot and Protection-Bot are linked and ops in channel
Op-Bot is configured +bitch, -enforcebans and +stopnethack for the channel. If anybody enters with Server-op or however gains op illegally the bot deops him and sets a ban. (Of course you have to set the channel -autoop, since there's no channel security with it!). The bot doesn't fulfil any other operations or tasks. In an ideal setup the bot should ignore public chatter in channel and any ctcp action done to it.
Public-Bot is, as the name already says it, a bot for public relations on which every one in the channel can easily get an account with hello or by a given script. It's also configured -enforcebans and besides this uses +greet to enable user greeting and -bitch to disable the op protection. This bot monitors public chatter in channel and reacts to it via given triggers with scripts like !seen, !top10 or whatever you like. It also bans people who disobey the channel rules (no colours, etc. [defined in scripts]). This bot should answer guarded ctcps to inform the channel users of its existence as a bot. This type of bot is usually heavily loaded (average channel with about 20-30 users) and shouldn't be used for anything else.
Protection-Bot alone uses the +enforcebans option to kick people from the channel. As you can see, it's the only bot that actually kicks users. This bot should also care about net-splits and the channel limit (dynamic limit settings) or any flood-nets. It also has set -bitch to allow anyone be op (since it doesn't care about it, Op-Bot does) and ignores any chatter in channel and doesn't answer to any ctcps or msgs. This bot should be running on the most stable and fastest shell available. Only owners should have an account on this bot.

As you can see, each bot is adjusted for its task and ignores everything else around it. Of course this can be very dangerous as one bot can easily become unavailable and then there's no substitution available. Fortunately this setup is pretty open, so you can easily expand the bot infrastructure. For example you can set up a second Op-bot and two more Protection-bots to ensure some backup service if one of them goes down. Of course you can start up as many bots as you like as long as they don't interfere each other. There might be problems with some scripts in this setup, but with a little optimisation you can easily adapt them (e.g. two bots responding to !seen, etc.).

b) Client Count

In nearly every channel there's sooner or later a discussion about the use and the count of bots in channel. I don't want to start it here again but I want to inspect the count of clients in channel further more.
There isn't a magical number that works on all channels, but generally there are two rules:
  • Use at least 2n+1 clients who care about mass deops where n is the number of allowed -o modes per command.
  • The more clients have ops in your channel, the more the channel gets attractive for takeover people. (Imagine: a channel with about 10 bots and an average of 5 users...)
    Personally I think that 10 reacting clients ought to be enough in most cases.

But even these two points don't count in general. If you're already in trouble (there's a script kiddie trying to takeover the channel) and you don't want to loose the control about the channel (see also: V. Social Group / Takeover Problem) there is no other way to protect yourself than to load clients into the channel. Such constellations make it difficult to netsplit takeover the channel and it maximizes the effort to take it down (i.e. by smurf).


c) Eggdrop's role in the model

 Eggdrop is a very good program and predestinated for channel security (it was coded for peace, and not for war). I don't want to list all it's capabilities and advantages here, everybody who reads this should have a clue how Eggdrop works and how it behaves in this or an other way.
Anyway, since I'm in the Eggdrop development team I have a pretty close look on the development and I like the way it develops. The 1.5 tree at the moment and the 1.7 tree in future are going to more stability, easier handling and more features.
Personally I don't think that any channel that's used mainly for chatter can be really protected without an Eggdrop.
Please halt and read the next chapter and chapter V. (V. Social Group / Takeover Problem) before you start buying shells and installing Eggdrops all over the place!

d) Eggdrop - the only solution?

 Eggdrop can do a lot of things and is capable of nearly everything, but good channel security concept doesn't rely on only one type of protection. Furthermore a mix between Eggdrop and other irc clients will do fine. Other interesting protection clients would be BitchX screens or psyBNC bouncers. BitchX has scripting support, too and therefore can interact nicely with Eggdrops. psyBNC is a good do-nothing-just-sit-in-channel client which control can be taken at any time by any other client (i.e. Eggdrop). An advantage of such a psyBNC bouncer is that you can connect from one running process on shell to 100 different servers using different vhosts. So it's a good idea to start a pre-configured psyBNC to join the channel with 30 or so connections if you're channel is under attack.

e) Exempts/Invites for Important People

 IrcNET support e/I modes, and it's advised to set sticky invites / exempts for people on the channel who are authorized to negotiate with takeover kiddies, since sometimes the channel is just simply set to +i.
You have to be careful not to set all owners, masters and bots on the e/I list, since the mode list can cope only 30 modes, and if you have 3 bots and 3 masters, you already filled the mode list with 12 modes. Usually you should set one or two persons on e/I.

Back to the top

II. Eggdrop Botnet

Any given bot security concept will fail sooner or later, if op and reop isn't handled carefully in channel. To ensure secure op giving (no auto-op to faked host masks) we have to make the bots communicate with each other over the botnet. Such a botnet has beside this simple task other useful functions, for example it allows coordination of scripts and retaliatory action against attacks.

a) Topology and Hubs

 A botnet is typically installed in the hub-leaf (star/tree topology) or the straight-line (bnc) way.

If you decide to use the bnc model you risk a high possibility of a lag in your botnet, since the whole botnet is as fast as its lowest bot connection. Such a botnet would look like this:

HUB-BOT (Protection)
  `--LEAF-BOT 1 (Public)
       `--LEAF-BOT 2 (op)

In the second, the tree model there's a central hub that connects every other bot. It's unlikely that big parts of the botnet will start to lag, as they are cross linked.

HUB-BOT (Protection)
  |--LEAF-BOT 1 (Public)
  `--LEAF-BOT 2 (op)

Of course some situation require the combination of both types, but normally you shouldn't use the bnc model.
If you use more then one bot for each of the above mentioned tasks (3 for each tasks are minimum) it's wise to install so-called sub-hubs, who distribute their user files to their leafs and lessen the load on the main hub.
Such a botnet would look this way:

HUB (Protection)
  |-+Level 1 LEAF (Protection)
  |-+Level 1 LEAF (Protection)
  |--Level 1 SUB-HUB (Public)
  |    |-+Level 2 Public Leaf 1
  |    |-+Level 2 Public Leaf 2
  |    `-+Level 2 Public Leaf 3
  `--Level 1 SUB-HUB (op)
       |-+Level 2 op Leaf 1
       |-+Level 2 op Leaf 2
       `-+Level 2 op Leaf 3

Now if you continue this thought, you'll see that it's very good to have one level 2 hub for each task and one absolutely no function level 1 hub bot. To ensure that all those hubs are always working correctly, you should use a backup bot for each hub you use. Finally those hubs mustn't be sitting on irc or even in your channel, since they have to be protected because the survival of your botnet depends on them. So you should place them as limbo hubs (no-irc-hubs) somewhere on a good and very stable server.
Such a "perfect" botnet would look similar to this:

Level 1 HUB 1 (limbo)
  |--Level 2 SUB-HUB 1 (Protection,limbo)
  |    |-+Level 3 Protection Leaf 1
  |    |-+Level 3 Protection Leaf 2
  |    `-+Level 3 Protection Leaf 3
  |--Level 2 SUB-HUB 3 (Public,limbo)
  |    |-+Level 3 Public Leaf 1
  |    |-+Level 3 Public Leaf 2
  |    `-+Level 3 Public Leaf 3
  |--Level 2 SUB-HUB 5 (op,limbo)
  |    |-+Level 3 op Leaf 1
  |    |-+Level 3 op Leaf 2
  |    `-+Level 3 op Leaf 3
  +
Level 1 HUB 2 (limbo,alternate,equal to Level 1 HUB 1)
  |--Level 2 SUB-HUB 2 (Protection,limbo,alternate to Level 2 Protection SUB-HUB)
  |--Level 2 SUB-HUB 4 (Public,limbo,alternate to Level 2 PUBLIC SUB-HUB)
  `--Level 2 SUB-HUB 6 (op,limbo,alternate to Level 2 op SUB-HUB)

With this infrastructure you should have a very stable and secure botnet and verification that each bot gets op when it requests it. Also each operation in the channel is ensured by at least three bots.
When deciding, which bot should be noirc and fulfil which tasks, you have to take several fact into mind. Both noirc bots should run on very stable and good connected servers to ensure maximal availability. They also must not run on a shell where other ircbots run, since this enhances the possibility against an attack against this box. The SUB-HUB's shells for example should be chosen by looking at all available shells and their network connection among themselves. Protect SUB-HUB should run on a shell with good connections to all protection leafs to ensure a nearly real time communication among them.

b) Sharing / Eggdrop Account Management

 One point we haven't looked at yet, is the distribution of access rights in our botnet. We have to divide here three groups of users, too.

  • Owner (access on every bot)
  • Master (access only on Op-Bots, partyline, adds Ops)
  • Op (access only on Op-Bots, no partyline)
  • Everybody (access on Public-Bots, including partyline)

Looking from the main level 1 hub to the very last level 3 leaf on the distribution process of accounts, it should be this way:
Level 1 hub shares all his data with all level 2 sub hub's. These share their data as followed:
  • The protect level 3 leafs get only b/e/I modes plus f/m/n users
  • The op leafs get all data beside b/e/I modes
  • The public leafs share only f/m/n users
At present this setup of user file sharing is not possible, due to limitations in the sharing code of Eggdrop. Maybe one day this feature will be available or I'll code something like this. At the moment you have to use scripts for this job or do it manually.

Back to the top

III. Stability Of Client Presence In Channel

The stability of your client connections to the irc network is one of the most important things. Nothing is more annoying and counterproductive then a bot cycling the channel over and over and the resulting opping, etc. It's not good for the channel either, when people connect to IrcNET and can't join the channel because it's juped (netsplit) or it's empty (netsplit, too).
Read in this chapter what you have to look after if you want to avoid such bad behaviour.

a) Choosing Shells for Clients

 Most often people can't choose from where you want your clients to connect to an irc network. But if you have the possibility to choose (by buying a shell), you should keep a look at two important points:
  • Choose a server from which runs as sparsely as possible bots. This minimizes the risk that the server gets packeted by a scripts kiddie who doesn't like any other bot on the same machine.
  • Choose a server from which you have a good connection to at least two irc servers, or alternatively, has a good backbone to enable many connections to serve as a hub shell.
The best shells available are the ones you get by friends from personal servers at ISPs or universities. If you don't know people who could donate you a shell, you are in bad situation - you have to buy a shell. :-(

b) Choosing Servers for Clients

 As you start choosing servers for your clients, you should first get a map of the structure of your network. You can use for example the Irctree module or fall back on official pages like http://irc.fu-berlin.de/ircmap.html (a link map of the german ircnet).
Next you have to check how "far" away (with traceroute) your shells are from the chosen servers. On the next step you should try to place on each important hub one of your bots, so in case of a netsplit, as many as possible servers will still have a client registered for your channel.
If you take for example IrcNET, you simply can't put on every important hub an own bot, so you have decide which hubs are important for you. If we stay on IrcNET it would be of great use to have a bot on a finish server, preferable irc.funet.fi, since this server is the main IrcNET hub. But on the other hand, if you're maintaining a local channel only (i.e. a city channel in Taiwan) it's unlikely you get a takeover via netsplit from the other end of IrcNET (i.e. Spain or so). In such cases you should try to get as many irc servers in your client list as possible which can be connected from your country or your neighbouring country, since chance is bigger that a takeover or a join will happen from there then from anywhere else (Why should someone from Spain attack or join a Taiwanese channel? The chance is bigger that somebody from China will do).

c) Eggdrop Versions

 When you install your Eggdrops, you should remember not to use same version on every bot (look here for Eggdrop version information). If you're using Eggdrops from the development tree you should at least have ten days between your versions to give developers enough time to fix any bugs that occur. A stable and reliable configuration could look like this:

  HUB 1 [version A - 3 months old cvs]
   |--SUB-HUB 1 (Protection) [version C - 1 month old cvs]
   |    |-+Protection Leaf 1 [version E - latest cvs]
   |    |-+Protection Leaf 2 [version F - 10 days old cvs]
   |    `-+Protection Leaf 3 [version G - 20 days old cvs]
   |--SUB-HUB 3 (Public) [version C - 1 month old cvs]
   |    |-+Public Leaf 1 [version E - latest cvs]
   |    |-+Public Leaf 2 [version F - 10 days old cvs]
   |    `-+Public Leaf 3 [version G - 20 days old cvs]
   |--SUB-HUB 5 (op) [version C - 1 month old cvs]
   |    |-+op Leaf 1 [version E - latest cvs]
   |    |-+op Leaf 2 [version F - 10 days old cvs]
   |    `-+op Leaf 3 [version G - 20 days old cvs]
   +
  HUB 2 [version B - 4 months old cvs]
   |--SUB-HUB 2 (Protection) [version D - 2 months old cvs]
   |--SUB-HUB 4 (Public) [version D - 2 months old cvs]
   `--SUB-HUB 6 (op) [version D - 2 months old cvs]
Of course this scheme can't be realized 100% in reality. You have to look further more for big changes in the development of Eggdrop. Therefore a weekly checkout of the latest Eggdrop dev version with the study of the appropriate UPDATES file is necessary.
If you're using only stable released versions, you should try to use always the latest version on every bot, since stable releases don't contain new bugs but fix old ones. For more secure ness you should keep at least some bots in every groups and all backup hubs at an older, stable version, preferable the last stable version from the last development cycle (i.e. if the latest stable bot is 1.6.4 you should use the latest pre-version stable bot, i.e. 1.4.4 for your backup hubs)

Back to the top

IV. Security in Practice

This chapter gives you some examples of concept on irc that secure a channel pretty much. Of course, the other points mentioned on this page shouldn't be ignored.
One point, which is common to all concepts here, is that every channel on a network that is susceptible to netsplit takeovers should be held secret (+s) to minimize such attacks. Of course not every channel can be held this way, since some channels want advertisement through the /whois information of its users.
All these techniques described below aren't a cure for every problem. In case you have to define for yourself, which of those techniques described below fits your needs.

a) Regulars Only Channel

 This concept relies on a channel, which is set to invite only (+i). Members can invite themselves by the bot or other clients in the channel.
This type of concept is pretty secure. It gives people who try to join a pretty neutral ""This Channel is invite only" message instead of the, also possible "You're banned from this channel" message. A protection via the *!*@* ban is also possible, since people can still join the channel if they're invited (new in ircd 2.10)

b) Country / local Channel

 The "Country / local Channel" concept works similar to the Regulars Only Channel concept. But instead of invites being triggered by clients inside the channel, a sticky invite (+I) mode is set to, for example in a German only channel, "*!*@*.de". All people with German host masks are able to join now and you can still ban some using the +b mode. Of course, not all ISPs use in Germany use ".de" domains, some also use ".net". In this case you have to set a second invite on "*!*@*.net".

c) Auxiliaries Concept

 In my home channel we have usually about 7 bots. As to the statistics, there's always one or two bots missing, due to server downtime, netsplit, etc. But if the number bots get below a certain level, my botnet calls auxiliary clients from an other channel. If the number rises again, the other clients leave. Of course these other clients mustn't be in an other channel, but we cooperate with this other channel and there's a 100% trust between us. We also plan for the future to start some psyBNC bouncers automatically, which connect to irc and just sit there and do nothing.
A script which acomplishes this task is cdiss.tcl, a netbots component written by me for this use. You can find it in the components section of this page.

d) Limit Concept

 Limiting a channel is a pretty good mechanism to avoid the join of large flood nets. The limit has to be set dynamically to x+n, where x is the count of users in channel and n is the grace limit of people allowed to join before the next raise.
Good limitation script don't change after each join, since it's just annoying if the limit is changed always from i.e. 31 to 32 to 31 to 32 and so on.

e) Ban Management

 There are two types of hostmasks a user can have when joining your channel, a normal one (resolving) or an ip numeric one (not resolving). When you ban an intruder with his resolving hostmask, he still rejoin the channel with a non-resolving version. I once had such a guy, and it was a pain since I had to enter each ban twice, and shortly after my ban list was full. IrcNET's ircd 2.10 solves this problem pretty good, since when an ip (or an ip range) is banned, the resolving hosts are banned either. Therefore it is advisable to keep as much bans as possible as ips (-ranges) and use a script which checks all joing resolving hosts against the bots internal ban list. Of course, not all bans can be set in ips (for example the ban of a complete country *.cx).
A script which accomplishes this task is banmanagement.tcl, it checks on join if a not resolved ip is banned as host and vice versa.

Back to the top

V. Social Group / Takeover Problem

Every channel forms some kind of a social group. Thereby it's not important if the group meets in this channel for small talk, serious discussion, or the exchange of free software. Such a community consists of a lot of regular channel users (mostly ops) and irregulars, people who join to ask something or because they're looking for something.
Anyway in most cases it's not important how the channel they're in is named. If it's #foo or #foo2 is really not important. However there are also channels where this might be important; Channel, which names indicate the social group or intention (city names, #flirt, etc.) a rare and something like a marketing instrument.
I'm definitely against retakes as long as those "takers" don't abuse their new op privileges. As for abuse I count the modes +i,+m,+b,+s and +p if they weren't set there before the takeover. For chatting purposes it's not important who has got op.
I hope I made my point clear. I'm for secure channels and I don't care who has ops as long as the chatting habits in this channel aren't interrupted.

Back to the top



Back to the main page

©1999, 2000, 2001 by [email protected], 03 July 2000. CONTACT