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.
a) Tasks and Services in a ChannelOverlooking the various needs of an average channel I see three major tasks which has to be performed:
Scenario: Op-Bot, Public-Bot and Protection-Bot are linked and ops in channel
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 modelEggdrop 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 PeopleIrcNET 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|
a) Topology and HubsA 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 ManagementOne 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.
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:
|Back to the top|
Read in this chapter what you have to look after if you want to avoid such bad behaviour.
a) Choosing Shells for ClientsMost 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:
b) Choosing Servers for ClientsAs 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 VersionsWhen 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|
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 ChannelThis 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 ChannelThe "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 ConceptIn 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 ConceptLimiting 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 ManagementThere 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|
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|