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, cool@modem36.ppp.yourisp.net, 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 All Protection, xchannel.tcl or sentinel.tcl, which can be found in the Tcl Archive. In addition, a channel userlimiter is recommended to prevent hundreds of flooders joining simultaneously.
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 your@email.address.com < /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.
