zynk/irssi
2
0
Fork 0
mirror of https://github.com/irssi/irssi.git synced 2026-08-18 08:02:13 +02:00
Code Issues Projects Releases Packages Wiki Activity

Added bot plugin, it also has almost-functional botnet.

Browse source 
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
This commit is contained in:
Timo Sirainen 2000-05-25 11:30:47 +00:00 • committed by cras
commit 76605ad0ae
41 changed files with 2809 additions and 246 deletions
Download patch file Download diff file Expand all files Collapse all files

393
docs/botnet.txt
View file

@ -1,163 +1,316 @@
HISTORY
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 :)
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.
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
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..
Strange, again the same day. I really didn't plan this :)
Reformatted the text, added lots of text, implemented more of the
stuff.
config file:
mybotnet =
{
priority=n;
nick=mybot;
bots=
(
{ host="another.org"; port=5567; password="blah";
valid_addrs=("*.another.org"); },
{ host="blah.ircnetthing.net"; password="blah";
valid_addrs=("*.ircnetthing.net", "*.blah.org"); },
{ host="some.thing.net"; password="blah";
valid_addrs=("some.thing.net"); }
);
}
1. General
When connecting to botnet, it first tries to connect to the first bot
in bots list, then the second, etc. Setting port to 0 will prevent
connecting to the bot.
1.1 Description
Login:
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.
First host checks what client is connecting from bots' valid_addrs. If
there's no matches it just disconnects the client.
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.
CLIENT: PASS blah
HOST : (if error, disconnect)
CLIENT: NICK nick
HOST : (if nick already in use) NICKERROR
CLIENT: PRIORITY=n
HOST : MASTER nick
HOST : CONNECTED
1.2 Configuration
Then host sends a list of all connected bots in botnet:
BOTINFO nick connected-to-nick address priority
example config file:
Now we're connected to botnet, rest of the commands will be send to
everyone. Commands are the following format (I won't write the nick
from now on):
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.*" ); }
);
}
nick COMMAND [command specific data..]
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.
After connection is established with the client, host sends (except to
the connected client):
BOTNEW client_nick client_address client_priority
1.3 Botnet master
Master is the client with the highest priority, if there's multiple
with the same priority, the one who's nick is the first in alphabet
"wins" and says:
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
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.
Also after connecting, client could check if it's priority is bigger than
current master's and make itself the master.
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.
Bots should every now and then check if their connections are active by
sending PING, the other side replies with PONG. If PONG isn't received
for a while (3 min?), the connection should be closed. If there's more
bots behind the lost bot, either side should try to reconnect to the
other one. Also if there's too much lag (>30sec) for some bots, their
priority could be temporarily lowered. When something urgent happens
and there's a lot of lag, each subset of bots should try to behave
independently.
1.4 Command format
When connection is closed to some bot, a notice is sent:
BOTQUIT nick
Commands that are sent inside botnet are in the following format:
After bot is (dis)connected to some irc network and is ready to take
commands, it sends notice:
BOTCONNECT ircnet (where ircnet is network's name, like IRCNet, EFNet, ..)
BOTDISCONNECT ircnet
<from_nick> <to_nick> COMMAND [command specific data..]
After joining/leaving channels, bot sends notice:
BOTJOIN ircnet #channel
BOTPART ircnet #channel
If to_nick is '-', the command should be sent to everyone.
After BOTJOIN, master tries to op the bot. When bot receives +o, it replies:
BOTOP ircnet #channel
If it's the first opped bot in channel, master orders the bot to op the rest
of the bots.
2. Handshake
Or after kicked or when being unable to join..:
BOTKICK ircnet #channel
BOTBANNED ircnet #channel
BOTCANTJOIN ircnet #channel
First host checks from bots' valid_addrs who is connecting. If
there's no matches it just disconnects the client.
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
joining (so it won't get autorejoin ban). When received BOTBANNED, master
tries to unban bot, BOTCANTJOIN results as invite to channel.
CLIENT: PASS <password>
HOST : (if error, disconnect)
When master notices that bot is the first one joined to channel, it asks bot
for channel information:
CLIENT: NICK <nick>
HOST : NICKERROR | CONNECTED
BOTCMD nick ircnet NAMES #channel
BOTCMD nick ircnet WHO #channel
BOTCMD nick ircnet MODE #channel
BOTCMD nick ircnet MODE b #channel
BOTCMD nick ircnet MODE e #channel
BOTCMD nick ircnet MODE I #channel
If nick is already in use, the host sends NICKERROR and waits for
new nick.
Next command is sent right after getting answer from the last query. It's also
possible that if several bots join immediately after the first bot, the
commands are shared between all the bots. After getting the results, the bot
replies:
Now we're connected to botnet. The commands from now on use the
format specified in section 1.4.
BOTREPLY ircnet <reply>
Both the client and the host sends information to other side of
all the clients they serve (if any):
Bots should cache the information as much as possible, at least NAMES command.
BOTINFO <nick> <connected_to_nick> <priority>
Every channel has a priority: LOW, NORMAL, HIGH.
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.
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.
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:
In NORMAL channels, the most urgent operations (kicks, ops, deops) are
performed quite soon even while bots are busy handling HIGH priority
commands.
BOTINFO bot highbot 10
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.
And the bot already exists, the BOTINFO is changed to:
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.
BOTINFO bot2 highbot 10
Channel's priority can also be set manually:
CHPRIORITY ircnet #channel <LOW/NORMAL/HIGH>
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>
Copyright (c) 1999 Timo Sirainen