mirror of
https://github.com/irssi/irssi.git
synced 2024-10-27 05:20:20 -04:00
76605ad0ae
Changed configure.in's functionality so that you could tell what modules you want to build in main irssi binary and it will create automatically the .c files that need to call the module_init()/deinit() functions. Fixed several minor things.. git-svn-id: http://svn.irssi.org/repos/irssi/trunk@230 dbcabf3a-b0e7-0310-adc4-f8d773084564
317 lines
9.5 KiB
Plaintext
317 lines
9.5 KiB
Plaintext
|
|
Irssi's botnet description
|
|
|
|
Copyright (c) 1999-2000 Timo Sirainen
|
|
|
|
|
|
0. History
|
|
|
|
draft v0.1 : 21.8.1999
|
|
|
|
Just a first draft of my botnet design I did on a boring friday
|
|
work afternoon :) I'll try to implement this to irssi some day, it
|
|
feels pretty interesting now so it might be pretty soon even. Any
|
|
comments are welcome :)
|
|
|
|
draft v0.2 : 21.11.1999
|
|
|
|
Exactly three months since the first draft :) Now I actually have
|
|
some code done, just committed pretty simple botnet to irssi CVS.
|
|
Made several changes to this document.. Still missing much details
|
|
but the basic idea should be clear.
|
|
|
|
draft v0.3 : 21.05.2000
|
|
|
|
Strange, again the same day. I really didn't plan this :)
|
|
Reformatted the text, added lots of text, implemented more of the
|
|
stuff.
|
|
|
|
|
|
1. General
|
|
|
|
1.1 Description
|
|
|
|
A small description of what botnet would do: A group of bots
|
|
efficiently working together to perform their tasks. Like when
|
|
someone's trying to take over your channel, bots will quickly
|
|
decide who deops/kicks whom instead of multiple bots deopping or
|
|
trying to kick the same people.
|
|
|
|
Irssi's botnet is pretty much based on trust. Some malicious bot
|
|
can quite well mess up the whole botnet. Connecting the bots to
|
|
each other via ssh would be a good idea.
|
|
|
|
1.2 Configuration
|
|
|
|
example config file:
|
|
|
|
mybotnet =
|
|
{
|
|
priority=5;
|
|
nick=mybot;
|
|
uplinks = (
|
|
{ host = "main.botnet.org"; password = "mypass"; },
|
|
{ host = "alter.botnet.org"; password = "pass2"; }
|
|
);
|
|
downlinks = (
|
|
{ password = "thepass"; valid_addrs = ( "192.168.0.*" ); },
|
|
{ password = "blah"; valid_addrs = ( "*.botnet.org" ); },
|
|
{ password = "localpass"; valid_addrs = ( "127.*" ); }
|
|
);
|
|
}
|
|
|
|
When connecting to botnet, the bot first tries to connect to the
|
|
first bot in uplinks list, then the second, etc. Setting port to -1
|
|
will prevent connecting to the bot, 0 uses the default.
|
|
|
|
1.3 Botnet master
|
|
|
|
To avoid total chaos inside botnet, the bots shouldn't do (almost)
|
|
anything without a command from botnet's master. The master should
|
|
know everything, and give commands to clients that can perform the
|
|
task best.
|
|
|
|
Master is the bot with the highest priority. If there's multiple
|
|
with the same priority, the one that already was the master will
|
|
stay master. When joining two botnets to one, the uplink's master
|
|
stays. If link to master breaks, the closest bot to it will choose
|
|
a new one.
|
|
|
|
The priorities should be given so that the bots that have the
|
|
fastest connections and are in the middle of the botnet have the
|
|
highest priorities.
|
|
|
|
1.4 Command format
|
|
|
|
Commands that are sent inside botnet are in the following format:
|
|
|
|
<from_nick> <to_nick> COMMAND [command specific data..]
|
|
|
|
If to_nick is '-', the command should be sent to everyone.
|
|
|
|
|
|
2. Handshake
|
|
|
|
First host checks from bots' valid_addrs who is connecting. If
|
|
there's no matches it just disconnects the client.
|
|
|
|
CLIENT: PASS <password>
|
|
HOST : (if error, disconnect)
|
|
|
|
CLIENT: NICK <nick>
|
|
HOST : NICKERROR | CONNECTED
|
|
|
|
If nick is already in use, the host sends NICKERROR and waits for
|
|
new nick.
|
|
|
|
Now we're connected to botnet. The commands from now on use the
|
|
format specified in section 1.4.
|
|
|
|
Both the client and the host sends information to other side of
|
|
all the clients they serve (if any):
|
|
|
|
BOTINFO <nick> <connected_to_nick> <priority>
|
|
|
|
BOTINFOs must be sent sorted so that connected_to_nick bot is
|
|
always known. Like first comes the bots connected to the
|
|
host/client, then the bots connected to them etc.
|
|
|
|
If the client had downlinks, nick collisions might happen. The
|
|
uplink is responsible for noticing them from BOTINFO commands.
|
|
It should automatically replace the nicks with new ones and
|
|
send nick change command to client and all it's downlinks. For
|
|
example if host received:
|
|
|
|
BOTINFO bot highbot 10
|
|
|
|
And the bot already exists, the BOTINFO is changed to:
|
|
|
|
BOTINFO bot2 highbot 10
|
|
|
|
And the client and it's downlinks are notified:
|
|
|
|
BOTNICK bot2 bot
|
|
|
|
After sending BOTINFOs, the host tells the current master:
|
|
|
|
MASTER <nick>
|
|
|
|
The client now checks if it's priority is higher than the current
|
|
master's. If it is, it will send the MASTER command without any
|
|
parameters.
|
|
|
|
|
|
3. Bot connections
|
|
|
|
3.1 General
|
|
|
|
Everyone's connections should be kept in n-way tree. Example:
|
|
|
|
|
|
[highuplink]
|
|
_____________/ | | \
|
|
/ | [h5] [h6]
|
|
[h1] | / | \
|
|
/ \ | [h7] | [h8]
|
|
[h2] [h3] | | \
|
|
| [uplink] [h9] [h10]
|
|
[h4] / | \
|
|
[up2] | [up1]
|
|
/ | | |
|
|
[up3] [up4] | [up5]
|
|
|
|
|
[we]
|
|
/ \
|
|
[client1] [client2]
|
|
/ \
|
|
[c3] [c4]
|
|
|
|
|
|
Botnet should try to keep together even if some hub in the middle
|
|
crashes. Each bot should have at least two uplinks in case one
|
|
dies. For example if [uplink] dies, [we] and [up1] could connect
|
|
to [up2], and [up2] could connect to [highuplink].
|
|
|
|
When connection is closed to some bot, a notice is sent by the
|
|
bot's uplink:
|
|
|
|
BOTQUIT <nick>
|
|
|
|
The quit notice should be sent only about the bot that was
|
|
disconnected. Bots should figure out themselves the other bots and
|
|
remove them too from their lists.
|
|
|
|
3.2 Lag
|
|
|
|
Each bot should send PING commands to their up/downlinks every
|
|
now and then (1min?) to check that the connection is still active.
|
|
If the PONG isn't received in 10 seconds, it's priority should be
|
|
temporarily lowered to -1. If the PONG isn't received in 3
|
|
minutes, the whole connection should be closed.
|
|
|
|
Master should know lag times of every bots. It could then
|
|
automatically raise/lower bots' priorities depending on how big
|
|
their lag is. Master could also lower it's own priority and pass
|
|
the master status to someone else with lower lag.
|
|
|
|
If there's lot of lag (>3sec?) somewhere and something urgent
|
|
happens, the botnet could split and behave independently.
|
|
|
|
|
|
4. IRC networks
|
|
|
|
4.1 Server connections
|
|
|
|
When bot is connected to some irc server and is ready to take
|
|
commands, it says:
|
|
|
|
IRCJOIN <tag> <ircnet> <server> <nick>
|
|
|
|
Tag is the bot specific unique tag of the server, so that the bot
|
|
can connect multiple times to same IRC network. All IRC related
|
|
commands should specify the server tag where it should be sent.
|
|
|
|
If bot quits an irc network, it says:
|
|
|
|
IRCQUIT <tag>
|
|
|
|
4.2 IRC commands
|
|
|
|
Master asks a bot to send some command to IRC server by saying:
|
|
|
|
CMD <id> <tag> <command>
|
|
|
|
<command> can't really be anything, since the bot should also be
|
|
able to reply to it. The <id> is for identifying the command/reply
|
|
pair. Master should keep the command in memory until it receives
|
|
the reply:
|
|
|
|
CMDREPLY <id> <last> <reply>
|
|
|
|
The command could get a reply of multiple lines, so <last>
|
|
specifies if the reply is the last line (1 or 0).
|
|
|
|
If the command failed for some reason, the bot will reply with
|
|
|
|
CMDFAIL <id>
|
|
|
|
and master should send the command to some other bot.
|
|
|
|
4.3 Channels
|
|
|
|
When joined/left channels, the bot says:
|
|
|
|
CHANJOIN <tag> <channel>
|
|
CHANPART <tag> <channel>
|
|
|
|
After BOTJOIN, master tries to op the bot. When bot receives +o,
|
|
it says:
|
|
|
|
CHANOP <tag> <channel>
|
|
|
|
If it is the first opped bot in channel, master orders the bot to
|
|
op the rest of the bots.
|
|
|
|
If the bot is kicked, it says:
|
|
|
|
CHANKICK <tag> <channel>
|
|
|
|
When master notices that bot is kicked, it first checks if there's
|
|
any other opped bots in channel. If not, it waits for a random
|
|
pause, 5-10sec before letting the bot join the channel again so
|
|
that it won't get autorejoin ban.
|
|
|
|
If bot can't join channel, it says:
|
|
|
|
CHANBANNED <tag> <channel>
|
|
(or)
|
|
CHANCANTJOIN <tag> <channel>
|
|
|
|
When received BOTBANNED, master tries to unban bot or set a ban
|
|
exception. BOTCANTJOIN results as invite to channel.
|
|
|
|
4.4 Channel information
|
|
|
|
When master notices that bot is the first one joined to channel,
|
|
it asks the bot for some channel information:
|
|
|
|
CMD <id> <tag> NAMES <channel>
|
|
CMD <id> <tag> WHO <channel>
|
|
CMD <id> <tag> MODE <channel>
|
|
CMD <id> <tag> MODE b <channel>
|
|
CMD <id> <tag> MODE e <channel> (if IRC network supports this)
|
|
CMD <id> <tag> MODE I <channel> (if IRC network supports this)
|
|
|
|
It's also possible that if several bots join immediately after the
|
|
first bot, the commands are shared between all the bots.
|
|
|
|
Bots should cache the information as much as possible, at least
|
|
NAMES command.
|
|
|
|
4.5 Channel priorities
|
|
|
|
Every channel has a priority: LOW, NORMAL, HIGH.
|
|
|
|
Normally LOW operates just as NORMAL channels, except when some
|
|
channel has HIGH priority and bots are really busy, LOW channels
|
|
just wait until there's time for them.
|
|
|
|
In NORMAL channels, the most urgent operations (kicks, ops, deops)
|
|
are performed quite soon even while bots are busy handling HIGH
|
|
priority commands.
|
|
|
|
Channels shouldn't normally be HIGH priority, but if attack
|
|
against channel is detected (like someone comes from split, gets
|
|
ops and gets to op someone else), it's priority is set to HIGH.
|
|
When channel's priority is HIGH, botnet does everything it can to
|
|
get rid of unauthorized opped people as fast as possible.
|
|
|
|
LOW channel's priority can also be raised to HIGH, but it's
|
|
priority is dropped back to LOW if some NORMAL channel's priority
|
|
is raised to HIGH too.
|
|
|
|
Master notifies about channel's priority change by saying:
|
|
|
|
CHANPRIORITY <ircnet> <channel> <LOW/NORMAL/HIGH>
|
|
|