Sign in to follow this  

Protecting and securing your eggdrop

Rate this topic

Recommended Posts

Eggdrop Protection and Security

The Eggdrop bot has many potential vulnerabilities that can be exploited if you don't secure your eggdrop properly. Below are some tips to help you make your Eggdrop more secure.

Disable learn-users
Allowing users to add themselves to the eggdrop may be convenient, but since it allows anyone to add themselves to the eggdrop 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 eggdrop and added 1,000 new users. You should consider disabling learn-users and instead add users to the eggdrop manually using the .adduser and .+user commands. If you really want to allow users to introduce themselves to the eggdrop, 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 eggdrop. 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 eggdrop - the last thing you need is for a renegade +n to use your eggdrop for abusive purposes and get you kicked off the shell/vps.

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 eggdrop, typically by sending a /msg to the eggdrop to request ops. A more secure, though less convenient, way is to log into the eggdrop 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 eggdrop 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 eggdrop 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 eggdrop recognise a new hostmask. Change these commands to something else. 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, eggdrop will make your hostmask *!cool@* If you are a eggdrop owner or master, it's important to further restrict access by making more specific hostmasks - e.g. *!cool@* or perhaps *!cool@modem*

Enable protect-telnet
By default, anyone can telnet to your eggdrop 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!* Example - if the user's hostmask is *!cool@*, you would add -telnet!*@* to their list of hostmasks. This allows the * domain to telnet to the eggdrop and attempt to login as the user. The protect-telnet feature also applies to eggdrops linking in, so on a hub eggdrop you would need to add the approriate telnet hosts for each leaf eggdrop, 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!*@*

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 eggdrops
The listen command in your eggdrop's config file usually looks something like listen 54321 all, the "all" meaning connection attempts from both eggdrops and users are allowed. In most cases, leaves should not accept link attempts from other eggdrops, and changing "all" to "users", i.e. listen 54321 users, will ensure such attempts are rejected. Note that a user .relay from other eggdrops 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 eggdrops by commenting out the listen line with a hash (#) character and restarting the eggdrop. Having no listen port also means the eggdrop won't be vulnerable to telnet-based attacks. The downside is that the only way you'll be able to get on the eggdrop's console is by initiating a DCC session with the eggdrop 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 eggdrop can access your shell account through the eggdrop. 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.

Use tcl scripts you really need
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. Use tcl scripts with features you really need on your eggdrop. All the nice & funny scripts you find around may be buggy and unsecure. Look for functionality instead of fun in your eggdrop.

Disable the chanset command
A vulnerability in eggdrop versions prior to 1.3.25 allows users to utilise the .chanset command to make the eggdrop perform virtually any function. You should either disable the .chanset command, or upgrade to 1.8.x 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 from 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 eggdrops 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 eggdrop. 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 eggdrop 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 from 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. From 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. 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 eggdrop 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 eggdrop. You may wish to remove the j and k console flags as these can clutter things.

You may also wish to have your eggdrop's log from yesterday e-mailed to you, allowing you to review all activity that occurred on the eggdrop. To do this, you need to add a line to your crontab. To have your eggdrop mail you yesterday's log at 5:30am, you would put the line:

30 5 * * * mail < /home/username/eggdropdir/eggdroplog.log.yesterday

Note that the above should be pasted as one line. Also substitute the e-mail address and path to the eggdrop's log with your own.

Use services, but don't give your eggdrop 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/vps security become less of an issue, taking a lot of the worry out of running a channel and freeing up your eggdrop to perform other useful tasks. Make sure, however, that you do not give your eggdrops any sort of "founder" status. Eggdrops should only have enough access to get ops and perform their required function. Never store a services password on your eggdrop (or in its scripts) that would allow someone to gain enough status to change ownership of the channel if they cracked the eggdrop's shell.

DoS attacks
Denial of Service attacks are directed at the shell the eggdrop is on. Such an attack is typically a flood of some sort that causes the shell to become extremely lagged and eventually your eggdrop may disconnect from IRC. Unfortunately, there is little you can do to protect your eggdrop from serious DoS attacks, as it is dependent on on the ability of the shell to withstand such attacks. Choosing a shell/vps account with a high bandwidth connection and good firewall systems can help prevent less serious attacks from having any significant effects on your eggdrop, 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 eggdrops on different shells/vps 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 eggdrops 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/vps 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 eggdrops on the botnet, depending on how you have them set up) and take over any channels the eggdrop is in. Unfortunately, once the shell/vps is cracked, there is little you can do to save your eggdrop 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 eggdrop that gets cracked is a leaf eggdrop, then you'll be safe since the hub overwrites the leaf eggdrop's userfile. In reality, the user will still be able to control the leaf eggdrop, 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 eggdrops, the user can then access all your shells through the eggdrops and make a big mess. Using private-user can help prevent a botnet from being compromised in this way.

  • Thanks 1

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this | cel mai mare chat online din Romania