Setting Up a Botnet
One of the great features of Eggdrop is bot linking, allowing you to create your own 'botnet'. A botnet can consist of two linked bots to as many as hundreds of linked bots. If you're using an Eggdrop for channel management, the most important feature of linked bots is userfile sharing. With userfile sharing, the bots can keep their user lists, ban lists, and ignore lists in sync with one another. A botnet also has many other possible capabilities, such as allowing bots to op one another securely, and making all bots join a channel with one command.
Linking bots can be a confusing process for first timers, but it's quite simple if you know how. The first thing you need to do is chose a hub bot. The hub is the main bot which all the other bots on the botnet (which will become leaf bots) connect to. Even if you are only using two bots, it's best to use one as a hub bot, and the other as a leaf. The hub bot should be the most reliable bot on your botnet, running on a fast, stable, and secure shell - so keep that in mind when deciding which bot will be the hub.
Once you've decided on the hub, it's time to set up the linking. A typical botnet of just a few bots will have a structure like the one shown in the tree below:
BigBoy
|--Camelback
`--Mallard
The tree above shows a botnet of three linked bots. BigBoy is the hub bot, while Camelback and Mallard are leaf bots. In order to set up a botnet like this, you need to add each bot to each other bot's user file, then set certain flags for each of those bots. In the steps below, I'll refer to the nicknames of the bots above - just substitute your own bot nicks when following these steps.
Note that if you don't wish to set up userfile sharing, just skip the four steps marked with an (s).
1) First up, config file stuff - make sure any channels you want bots to synchronise information about (e.g. user flags, bans, etc.) are set to +shared in each bot's config file, and make sure the share and transfer modules are loaded (loadmodule transfer and loadmodule share).
2) On BigBoy (the hub bot), you need to add the leaf bots to the userfile. To add Camelback and Mallard, type .+bot Camelback and .+bot Mallard.
3) Set any ordinary user flags for the bots. Generally, bots should be given global f (friend) and o (op) flags. To do this, .chattr Camelback +fo and .chattr Mallard +fo.
4) (s) Give the bots the s bot flag. Type .botattr Camelback +s and .botattr Mallard +s. This makes the hub aggressively share its userfile with the leaf bots.
5) (s) Give the bots the s bot flag for each channel you want to synchronise information about, e.g. if the three bots are on #railroad and #trains, type .botattr Camelback |+s #railroad and .botattr Camelback |+s #trains, then do the same for Mallard. Alternatively, you can use the g flag by typing .botattr Camelback +g, instead of setting the s flag for each channel. The g flag simply makes the bot share information for all channels.
6) Repeat steps 2 to 5 for any other leaf bots to be added to the hub.
7) Now it's time to setup the hub on the leaf bots. Let's start with Camelback, so leave BigBoy for now and switch to Camelback's command console. First, you need to know the telnet address for your hub bot (BigBoy), which consists of the bot's host and port (the port will be whatever you set in the listen setting in BigBoy's config file). If BigBoy's hostname is [email protected] and the port is 11941, its telnet address is steam.trains.com:11941. You can then add BigBoy by typing .+bot BigBoy steam.trains.com:11941.
8) Set any ordinary flags for BigBoy, like you did for the leaf bots, e.g. .chattr BigBoy +fo.
9) (s) Give BigBoy the p bot flag by typing .botattr BigBoy +p. The p flag makes the bot passively share its userfile with the hub bot (i.e. the bot downloads the userfile from BigBoy).
10) (s) Give BigBoy the s bot flag for each channel you want to synchronise user information about, e.g. if the three bots are on #railroad and #trains, type .botattr BigBoy |+s #railroad and .botattr BigBoy |+s #trains. Alternatively, you can use the g flag by typing .botattr BigBoy +g, instead of setting the s flag for each channel. The g flag simply makes the bot share information for all channels.
11) Give BigBoy the h flag by typing .botattr BigBoy +h. The h flag makes the bot try to link to the hub automatically.
12) Within a minute, Camelback should attempt to link to BigBoy and (if you set up sharing flags) download the userfile.
13) Repeat steps 7 to 11 on any other leaf bots.
The above steps will link all your leaf bots to your hub bot, and (if you set up the sharing flags) userfile sharing will be active. Note that if you have protect-telnet enabled in the hub bot's config file, the connection attempts from the leaf bots will be rejected until you add a telnet host for each leaf bot. This is described here.
If the the hub bot goes down for any reason, leaf bots will automatically relink when returns. Some users may wish to set up an alternate hub, which the leaf bots will connect to if the hub goes down, using the a bot flag. If you wish to try this, as well as gain a better understanding of botnet configuration, refer to the Botnet Sharing and Linking guide that is included with Eggdrop.
Using Tcl Scripts
Using Tcl (pronounced 'tickle') scripts is the easiest way to add extra features to your Eggdrop. There are hundreds of Tcl scripts out there that add all sorts of interesting capabilities, such as advanced on-join greet functions, improved channel protection, additional public commands, trivia and other games... the list goes on.
Tcl scripts are often compressed with gzip, and have the .gz filename extension. You can extract these in Windows using 7-Zip or on the shell using the 'gunzip' command, e.g. gunzip scritptname.tcl.gz. Many scripts require configuration before you use them, so it's a good idea to open the script and read the documentation and settings before adding the script to your bot. Note that some scripts are in the Unix file format, and will not display properly in some Windows text editors (such as Notepad), but will look fine in others (such as Wordpad).
To add a Tcl script, you must copy the Tcl file to the /scripts directory of your Eggdrop. You then need to add a line to load the script at the end of your bot's config file. Near the end of the example config file, you'll see a couple of lines like this:
source scripts/alltools.tcl
source scripts/action.fix.tcl
If the script you want to add is called fun.tcl, you would add the following line just under the lines above:
source scripts/fun.tcl
Once you've placed the script in the /scripts directory and added a pointer to it at the end of the config file, type .rehash in the command console. This will load the script and it should be active and ready for use (note that some scripts may require you to shut down and restart the bot rather than just rehashing).
Check out the Tcl Scripts section for some of the best Tcl scripts. Also take a look at the Links section which lists several other sites with large Tcl script archives.
If you have some experience writing Tcl scripts and would like to write your own for Eggdrop, have a read through the Beginners Guide to TCL, and be sure to check out tcl-commands.doc in the /doc directory which contains information on all of Eggdrop's built-in Tcl commands. If you're completely new to Tcl, try the excellent Guide to TCL scripting for Eggdrop 1.6. And download yourself a copy of the Tcl Manual for quick reference.
Using Patches
Patches make direct modifications to the Eggdrop code. They're used primarily to fix bugs, and in some cases add new features or change the way a particular feature works. Upgrades to new versions of Eggdrop are also offered in patch form. Patches are more complicated to install than Tcl scripts, and are used much less frequently. You can find patches for Eggdrop at the large Tcl script archives you'll find in the Links section.
Patch files are generally distributed with the .patch file extension. You can only apply a patch to the original source directory of Eggdrop (you can not use it on an Eggdrop installation that was copied using make install). To apply the patch, copy it to the directory you extracted the Eggdrop source to (e.g. the /eggdrop1.3.27 directory). You must then run the patch program - if the patch you want to apply is called eggdrop1.3.27+thefix.patch, type the following in telnet:
patch -p1 < eggdrop1.3.27+thefix.patch
This will make any necessary modifications to the Eggdrop source code. Once patched, you will need to recompile the bot using make and install it with make install.
Using Language Files
Many of Eggdrop's functions can be made to display in languages other than English. This is achieved through the use of language files. Note that the following information applies to Eggdrop 1.4 series, which has better language support than earlier versions. Eggdrop 1.3 and earlier do not have the addlang, +lang and -lang commands discussed below.
Language files are located in your bot's /language directory. Currently, there are three types of language files:
- The core language files, such as core.french.lang, contain language text for most of Eggdrop's central functions.
- The filesys language files, such as filesys.french.lang, contain language text for the file system module.
- The wire language files, such as wire.french.lang, contain language text for the wire module.
In order to make the bot display text in your preferred language, you will require a core language file. For the file system and wire modules to display your language, you will need the additional filesys and wire language files. English, German and French language files are currently included with Eggdrop. You can find language files for other languages in the Eggdrop Files section. Note that language files often vary between bot versions, so it's a good idea to get language files for the version of Eggdrop that you're using. Older language files will generally work with newer version bots, but text for some functions may be missing.
Once you have your language file(s), place them in your bot's /language directory. If you're going to be using a particular language on your bot permanently, you should use the addlang <language> command in your bot's config file. For example - to load french.lang files, you would add addlang "french" to the top section of your bot's config file (see eggdrop.conf.dist for an example). You can also add/remove language files from the console using the .+lang and .-lang commands, but languages added with these commands will only be effective until the bot is shut down.
For more information about what language files are in use on your bot, use the .lstat command.
Bot Protection and Security
The Eggdrop bot has many potential vulnerabilities that can be exploited if you don't secure your bot properly. Below are some tips to help you make your Eggdrop more secure.
Disable learn-users
Allowing users to add themselves to the bot may be convenient, but since it allows anyone to add themselves to the bot it is not very secure (especially if the user gets partyline access when they introduce themselves). And the last thing you want is to find someone has msg flooded your bot and added 1,000 new users. You should consider disabling learn-users and instead add users to the bot manually using the .adduser and .+user commands. If you really want to allow users to introduce themselves to the bot, you should change the command to something other than the default 'hello'.
Choose owners carefully
Be very careful about giving out global owner (+n) status on your bot. You should consider not giving out +n status to other users at all, otherwise make sure you only give it to people you've known on IRC for quite a while and who can be trusted. Owner status allows a user to do practically anything with your bot - the last thing you need is for a renegade +n to use your bot for abusive purposes and get you kicked off the shell.
Don't use auto-op
Unless your Eggdrop is on a small, private channel which does not get many visitors you do not know, using auto-op greatly increases the risk of channel takeover. This is because, in order to get ops, a person only needs to match a hostmask of a user, and idents/hostnames can often be faked on IRC. It is best to make sure that users can only get ops after giving their password to the bot, typically by sending a /msg to the bot to request ops. A more secure, though less convenient, way is to log into the bot via DCC and use the .op command (though there is a risk here that the user could accidentally type in the wrong nick to op if they're not using their usual nick).
Password security
Don't choose an easily guessable password - make it a random combination of upper and lower case letters and numbers, or two words combined with a number - anything but an actual word. Also make sure when sending a msg to the bot containing your password (e.g. /msg botnick op <password>) that you don't do the /msg in a channel window - I've lost count of the number of times I've seen people msg their bot password to a whole channel because they accidentally left off the slash or something.
Rebind or disable the ident and addhost commands
It's a good idea to use msg commands other than 'ident' and 'addhost' for making the bot recognise a new hostmask. Change these commands to something else (as explained in the Setup guide). For even better security, you may wish to disable the commands without rebinding them, although this requires masters and owners to add new hosts for users manually.
Use specific hostmasks
If your hostname is, for example, [email protected], Eggdrop will make your hostmask *!cool@*.yourisp.net. If you are a bot owner or master, it's important to further restrict access by making more specific hostmasks - e.g. *!cool@*.ppp.yourisp.net or perhaps *!cool@modem*.ppp.yourisp.net.
Enable protect-telnet
By default, anyone can telnet to your bot and attempt to guess a user's password at the login prompt. Enabling protect-telnet in the config file will allow you to restrict telnet access to particular hosts. To give a user telnet access with protect-telnet enabled, you add a special telnet hostmask to the user record, in the format -telnet!*@their.hostname.com. Example - if the user's hostmask is *!cool@*.dudes.net, you would add -telnet!*@*.dudes.net to their list of hostmasks. This allows the *.dudes.net domain to telnet to the bot and attempt to login as the user. The protect-telnet feature also applies to bots linking in, so on a hub bot you would need to add the approriate telnet hosts for each leaf bot, in the same way you would for users.
Note that by default, Eggdrop gives the owner the -telnet!*@* hostmask, allowing any host to telnet in. You should make sure you remove this hostmask, and add a more specific one (e.g. -telnet!*@*.ppp.yourisp.net).
Also note that in versions of Eggdrop prior to 1.6, telnet!*@* (without a dash) is used instead of -telnet!*@*.
Allow only users to telnet to leaf bots
The listen command in your bot's config file usually looks something like listen 54321 all, the "all" meaning connection attempts from both bots and users are allowed. In most cases, leaves should not accept link attempts from other bots, and changing "all" to "users", i.e. listen 54321 users, will ensure such attempts are rejected. Note that a user .relay from other bots will still be accepted as it's classed as a user connection.
An even more secure option is to disable the listen port completely on leaf bots by commenting out the listen line with a hash (#) character and restarting the bot. Having no listen port also means the bot won't be vulnerable to telnet-based attacks. The downside is that the only way you'll be able to get on the bot's console is by initiating a DCC session with the bot on IRC. In most cases, disabling the listen port shouldn't be necessary and using protect-telnet as described above is adequate.
Disable the tcl, set, and binds commands
Using the .tcl and .set DCC commands, anyone with global owner status on your bot can access your shell account through the bot. Obviously, this is a bad thing, so you should make sure these commands are unbound in the config file. The .binds command is also used maliciously in many cases, and should be disabled if you don't use it.
Disable the chanset command
A vulnerability in Eggdrop versions prior to 1.3.25 allows users to utilise the .chanset command to make the bot perform virtually any function. You should either disable the chanset command, or upgrade to 1.3.25 or later and make sure must-be-owner is enabled.
Enable must-be-owner
This feature only exists in 1.3.24 and later versions. It allows only permanent owners (as set in the 'owner' setting in the config file) to use the .tcl and .set commands (assuming you have them enabled). In 1.3.25 and later, it also enhances the security of the chanset command, and in 1.3.26 you can set must-be-owner to 2 to also allow only permanent owners to use the .dump command.
Use private-user
If you have a botnet with bots sharing userfiles, you should consider using the private-user feature. This can significantly increase the security of your botnet, but all user changes (e.g. user additions, ident/addhost, password and flag changes, etc.) will need to be made via the hub bot. Note that only 1.3.27 and later have a properly working private-user - it is not effective on earlier versions - so if you want to take advantage of private-user your hub bot must be 1.3.27 or later.
Use good flood protection
Most people expect Eggdrops to be bullet-proof, but the reality is that, by default, they're quite vulnerable to basic types of flooding. Vulnerabilities to such things as CTCP floods, avalanche floods, and users with bogus usernames are fixed in the newer 1.3 versions - but you have to use the right settings. 1.3.21 and later have the kick-bogus option which should be set to 0 to prevent kick floods on bogus usernames, while 1.3.24 and later have the kick-fun flag which should be set to 0 to eliminate vulnerabilities to avalanche floods. 1.3.26 and later versions have the ctcp-mode setting, which you should set to 2, using an appropriate global-flood-ctcp setting such as the default 5:30.
For better flood protection, you should consider using a flood protection script such as sentinel.tcl, combined with a channel userlimiter script such as chanlimit.tcl.
Keep an eye on things
While you're online, you should open a DCC chat session with your bot and sit in the console. Make sure console modes m, b, s, c, o, and x are enabled (type .console +mcobxs), so you can see everything that's going on with your bot. You may wish to remove the j and k console flags as these can clutter things.
You may also wish to have your bot's log from yesterday e-mailed to you, allowing you to review all activity that occurred on the bot. To do this, you need to add a line to your crontab (if you don't know how to do that, read this section of the Setup guide for an example). To have your bot mail you yesterday's log at 5:30am, you would put the line:
30 5 * * * mail [email protected] < /home/username/botdir/botlog.log.yesterday
Note that the above should be pasted as one line. Also substitute the e-mail address and path to the bot's log with your own.
Use services, but don't give your bot full access
If your preferred IRC network has nickname and/or channel services and they are available to you, use them. DoS attacks and shell security (described below) become less of an issue, taking a lot of the worry out of running a channel and freeing up your bot to perform other useful tasks. Make sure, however, that you do not give your bots any sort of "founder" status. Bots should only have enough access to get ops and perform their required function. Never store a services password on your bot (or in its scripts) that would allow someone to gain enough status to change ownership of the channel if they cracked the bot's shell.
DoS attacks
Denial of Service attacks are directed at the shell the bot is on. Such an attack is typically a flood of some sort that causes the shell to become extremely lagged and eventually your bot may disconnect from IRC. Unfortunately, there is little you can do to protect your bot from serious DoS attacks, as it is dependent on on the ability of the shell to withstand such attacks. Choosing a shell account with a high bandwidth connection and good firewall systems can help prevent less serious attacks from having any significant effects on your bot, but there are few shells that are totally invulnerable. DoS attacks, such as the notorious 'smurf' attack, are the main reason why many IRC channels have a large number of bots on different shells to help protect the channel from takeover as a result of such an attack.
Shell security
Because of the seemingly endless number of new security holes and exploits appearing in components of the various flavours of Linux and FreeBSD and the services that are run on them, the Unix shell box of a commercial shell provider is always at significant risk of being 'cracked'. Because of the 'public' nature of commercial shell accounts - virtually anyone with a few spare dollars or someone else's credit card number can get an account, and there may be careless users who give out their account password to malicious hackers (crackers) - there may occasionally be a few bad eggs on the system who will attempt to compromise the security of the shell and gain control of all the accounts. In some cases, the shell may even be compromised remotely by a user without an account. If this happens, the user can then gain control of your Eggdrop (and possibly all of the bots on the botnet, depending on how you have them set up) and take over any channels the Eggdrop is in. Unfortunately, once the shell is cracked, there is little you can do to save your bot and channels.
Private shells are generally less vulnerable to being cracked, but unless you have friends with their own Unix shell boxes you'll have no option but to use a commercial shell provider. So, when choosing a shell provider, make sure you choose one with a reputation for good security and monitoring policies.
A common misconception is that if the bot that gets cracked is a leaf bot, then you'll be safe since the hub overwrites the leaf bot's userfile. In reality, the user will still be able to control the leaf bot, and if you're using a typical sharing setup, the user can gain control of all sharebots on the botnet. Furthermore, if you have the .tcl, .set, or .chanset commands enabled on these bots, the user can then access all your shells through the bots and make a big mess. Using private-user can help prevent a botnet from being compromised in this way.