Jump to content


Wall of Fame
  • Content count

  • Joined

  • Last visited

  • Time Online

    19h 56m 50s

Everything posted by zeke

  1. UrlTitle tcl

    Detects URLs from IRC channels and prints out the website title. DOWNLOAD LINK: ___ Detecteaza URL-urile de pe canalele de IRC si arata titlul website-ului. LINK DESCARCARE:
  2. Opening a telnet session directly to your bot is similar to opening a DCC chat session - you will be placed in the command console and can control your bot with DCC commands. The difference is that telnet is not dependant on IRC, so you don't need to be on IRC to telnet to the bot. To telnet to your bot, you must specify its hostname and port in your telnet client. The hostname is the same as your bot's vhost - e.g. if your bot's host on IRC is froo@cool.tclhelp.team, you would telnet to cool.tclhelp.team. The port you need to specify depends on the listen port you have set in the bot's config file, e.g. if you have listen 4941 all, you need to telnet to port 4941. If you have enabled protect-telnet in the bot's config file and are having trouble opening a telnet session with your bot, you'll need to check that you've created a telnet mask for yourself. A telnet mask looks like -telnet!*@host.goes.here. If you want to telnet from *.yourisp.net for example, you'll need to add that as a telnet host by typing .+host YourNick -telnet!*@*.yourisp.net.
  3. Your bot recognises you by the hostname you have on IRC (e.g. zeke@tclhelp.team). It compares this hostname with the hostmasks contained within your user record (e.g. *!zeke@*.tclhelp.team) and will recognise you if they match. If you change your ident or get a new ISP, your bot will not recognise you and will not respond to your DCC chat requests. Eggdrop has a built in msg command called ident that is used to make the bot recognise you after your hostname has changed. The syntax is /msg <botnick> ident <password> [nickname]. The nickname portion is only required if you're using a different nick from the one your bot knows you by (e.g. if your user record on the bot is 'froo' but you're using 'froo2' on IRC, you'll need to specify 'froo' as the nickname). Note that if you used the advanced or complete example config file that's included with Eggdrop to create your config file, your bot may have disabled the ident command, or you may have changed it to something different. Look for the following section in your bot's config file: # Many takeover attempts occur due to lame users blindly /msg ident'ing to the bot and attempting to guess passwords. We now unbind this command by default to discourage them. You can enable these commands by commenting the following two lines. unbind msg - ident *msg:ident unbind msg - addhost *msg:addhost To reactivate the ident command, add the following line just below the above lines: bind msg - ident *msg:ident If you'd like to set your ident command to something different, you can replace ident with another word (note that you don't change the *msg:ident bit - that stays the same). The ident function isn't the only way to add new hostmasks. You can add, remove and modify your hosts using the .+host and .-host DCC commands. Type .help +host and .help -host for more info on using these commands. Of course, to use these DCC commands, you must already be logged into the bot, so you'd have to add any new hostmasks before your ident and/or host changes.
  4. DCC CHAT AND PARTY LINE The great majority of Eggdrop's functions are controlled in a DCC chat session with the bot. DCC chat with the bot has two purposes - to use as a console for entering Eggdrop commands, and to use as a chat area. Simply DCC chat to the bot just like you would a normal user. You can also make the bot initiate the DCC session by typing /ctcp <botnick> CHAT, where <botnick> is the nick of your bot. This method is particularly useful if you're behind a firewall which prevents you from initiating the DCC session. When you've established a connection to the bot, you will be prompted for your password, and then automatically placed on the party line (the main chat area). You type in Eggdrop commands by preceding them with a period (e.g. .help, .bots, .whom, .+chan, etc.). Anything not preceded with a period is sent out to other users on the party line, just like a message sent to an IRC channel. There are also other 'channels' on the bot (other than the party line) which you and others can switch to and in this way the bot can act a bit like an IRC server. TELNET You can also access the command console and party line via a telnet session to the bot. To telnet to the bot, you simply enter its hostname and port (as specified by the 'listen' command in the config file) in your telnet client. You will be asked for your nickname and password on connecting. Once connected, you'll be at the console and on the party line just as you would if you'd opened a DCC session. Telnet is particularly useful if you need to connect to the bot but aren't able to DCC to it (e.g. when the bot isn't on IRC). If the text output appears incorrectly during the telnet session (e.g. each new line is indented by the length of the previous line), you may need to enable some type of "new line mode" in your telnet client's options. In PuTTY, for example, you would enable Implicit CR in every LF under Terminal. USING THE CONSOLE Eggdrop has a comprehensive internal help system. The first thing you should do when you've opened a DCC chat session with the bot is type .help. This will display most of the commands you can use. For more info about a particular command, you type .help <command>. The DCC chat session not only allows you to speak to users on the party line (and other internal 'channels') and use Eggdrop commands, but also lets you monitor your bot. Using the .console command, you can change the types of information displayed to you, e.g. you can choose to view commands used by others, view msgs and notices sent to the bot, view public messages to a channel, and so on. Your console settings also determine what IRC channel you're working with. For example, if your bot is on #monkey and #dolphins, you can set your console to either one of those channels. Many of Eggdrop's commands will apply to your current console channel, e.g. if your console is set to #monkeys and you use the command .op zeke, the bot will op 'zeke' on #monkeys. You can change your current console channel using .console <#channel>. You may save your current console settings using .save. MSG COMMANDS Eggdrop has a limited number of commands performed via msg, but a few of them are quite important, such as the op command and ident command. For a list of msg commands, type /msg <botnick> help. Additional msg commands may be added by certain Tcl scripts. Be very careful when using msg commands that include your password - if you usually type /msg <command> <password> in a channel window in your IRC client, you will eventually end up accidentally msging your password to the channel for everyone to see. PUBLIC COMMANDS Eggdrop has no built-in public commands (i.e. commands you type in the channel) except for 'seen'. If you have the seen module loaded (i.e. loadmodule seen in the config file) and the channel is set to +seen, then the bot will respond to the seen <nick> command in the channel. There are several Tcl scripts out there that add public commands to Eggdrop. For certain functions, such as info commands and games, this is fine. But using public commands for functions such as giving ops, adding users, jumping the bot to a new server, and so on can be insecure. Such scripts could allow malicious users to take control of your channel or Eggdrop, so a good public commands script for these types of functions must have a good authorisation system built-in, and preferably only make the commands available to users who are opped on the channel. Although some people think it looks cool to be able to use public commands without being opped, it is less secure. THE USERFILE Your Eggdrop's userfile controls which users can access the bot, and the level of access each of these users has. The userfile also contains the ban lists and ignore lists. Userfile management is one of the fundamental things you need to learn in order to use your Eggdrop effectively. When you first start your Eggdrop and introduce yourself using the hello command or equivalent, you will be added as the first user and be given all owner privileges (if you have learn-users switched off, the hello command will be deactivated once you've introduced yourself as owner). To display your userfile entry, type .whois <yournick> in the console. You will see a display similar to the following: HANDLE PASS NOTES FLAGS LAST YourNick yes 0 fjmnoptx 19:57 (partyline ) #monkeys fmno 18:44 #dolphins fmno 14 Apr HOSTS: *!mynick@*.myhost.net, *!mynick@123.456.789.* The information above displays the user's handle (the handle is simply the user's nickname on the bot), whether or not they have a password set, how many notes they have, their global and channel flags, where and when they were last seen by the bot, and their hostmasks. Below you'll learn how to manipulate the userfile. DISPLAYING ALL USERS To display all the users in your bot's userfile, type .match * 999. This will display a record similar to the one shown above for each user. ADD/REMOVE USERS There are three ways a user can be added to the bot. If you have learn-users enabled in the config file, anyone can msg the hello command to the bot and the bot will add them with the default flags (as set in the config file's default-flags setting). Otherwise, you may add a user using either the .adduser or .+user command in the console. If the user you want to add is in one of the bot's channels, then .adduser is the most convenient command. Make sure the channel the user is in is your current console channel (read Using the Console again if you're not sure about this), then type .adduser <nick>, where <nick> is the nickname of the user you want to add. The user will be added to the bot's userfile with the default flags, and their hostmask will automatically be added. The .+user command should be used when the person you want to add is not on IRC. Type .+user <nick> <hostmask> to add the user with the specified nickname and hostmask. Once a user has been added, they will need to set a password using the pass command. Tell the user to type /msg <botnick> pass <password> to set their password. You may instead wish to set a password for them using the .chpass command (explained below). To remove a user from the bot, simply type .-user <handle>. CHANGING A USER PASSWORD To set a password for a user or change their password, type .chpass <handle> <password>. You can unset the password by doing .chpass <handle> without specifying a password. USER FLAGS User flags determine what privileges a user has, e.g. whether or not they can get ops on a channel, which bot commands they can use, etc. All built-in flags are lower case alphabet letters. You can list all the flags by typing .help whois, but for now you only need to know the most important flags: v - voice o - op m - master n - owner f - friend p - partyline access Many of the user flags are separated into two categories - global and channel - while some flags are global only. The v, o, m, n, and f flags are examples of flags that may be global or channel-specific, while the p flag is global-only. Channel flags only apply to a specific channel, e.g. if you give someone the o flag on #monkeys, the user will only be able to get ops on #monkeys, but if you give the user a global o flag, they will be able to get ops on all channels the bot is on. Global flags are also more powerful in nature, in that they give the user access to more powerful bot commands than the equivalent channel flags. Flags are added to or removed from a user using the .chattr command. To add a global o flag, for example, you would type .chattr <handle> +o. To add a channel specific o flag, you would do .chattr <handle> +o <#channel>. Removing flags is much the same - to remove a global o it's .chattr <handle> -o, and to remove a channel o it's .chattr <handle> -o <#channel>. You can also add/remove multiple flags in one command, e.g. .chattr <handle> +fo will give the user the f and o flags. Be very careful when giving out a global n (owner) flag. This will give the user access to virtually all the commands on your bot, and depending on how you have the bot configured it may also give the user access to your shell account via the .tcl command. ADD/REMOVE HOSTMASKS The .+host <handle> <hostmask> command allows you to add hostmasks to a user, e.g. .+host hyena *!hyena@*.africa.net. To remove a hostmask from a user, use .-host <handle> <hostmask>. THE BAN LIST The ban list is a part of the Eggdrop's userfile specifically for storing bans. Bans are added to the bot's internal ban list (also called the enforced or permanent ban list) using the .+ban command. They may also be added automatically by the bot (e.g. in response to a flood) or by a Tcl script. Internal bans can either be global (they apply to all channels the bot is on) or channel-specific. A ban may be permanent or expire automatically after a set amount of time, and it may optionally be 'sticky' (the bot makes sure the ban is always active on the channel). Note that if you're using +dynamicbans in a channel's settings, a ban set in the bots internal ban list will be removed from the channel after ban-time minutes (as set in the config file), but it will remain in the internal ban list and will be reactivated whenever someone matching the ban joins the channel. If you're using +dynamicbans but want a ban to be active on the channel around the clock, you should make the ban sticky. DISPLAYING THE BAN LIST Type .bans to display all currently active global bans and channel bans (for the current console channel). To display both active and inactive bans, type .bans all. These lists will also display bans that are active on the channel but not in the bot's internal ban list (such bans will be preceded by an asterisk). ADD/REMOVE BANS Global bans are added using the command .+ban <banmask> (e.g. .+ban *!*lamer@*.isp.net). You can add a channel ban using .+ban <banmask> <#channel>. Bans added using these commands will be permanent (i.e. they will remain in the bot's internal ban list until someone manually removes the ban). You can remove a ban in one of two ways - using the banmask or reference number. The output of .bans all will display a reference number before each ban. If you want to remove ban number 4, for example, you would type .-ban 4. Keep in mind that a ban's reference number can change depending on the console channel you're using (e.g. if you type .console #dolphins, then .bans all, then .console #monkeys, then .bans all, the reference numbers for bans may be different in the two lists you displayed). To remove a ban by its banmask, simply use .-ban <banmask>. STICKY BANS You can make a ban sticky by using the .stick command with either the reference number or banmask, i.e. .stick <number> or .stick <banmask>. A sticky ban will be reactivated by the bot if anyone removes it from the channel. CHANNEL SETTINGS The way your Eggdrop acts and responds to events in your channel is largely affected by channel settings. Eggdrop has many built-in channel settings, and you can set different settings for each channel, allowing for extreme flexibility. When you first created your Eggdrop's config file and added entries for each channel the bot was to reside on, you would have encountered channel settings for the first time. In the setup guide, you may remember having seen the following: channel add #dolphins { options } channel set #dolphins+option -option You will notice that there are two types of channel settings. The first type are ones you set between the curly braces, such as idle-kick and flood protection settings (e.g. flood-join, etc.). The second type are on/off switches you set as part of a channel set command. These switches include options such as autoop, dynamicbans, revenge, etc. These settings are preceded by a + or - sign to specify whether or not you want the option to be active or inactive respectively. For more information about each channel setting and its function, refer to the example config file(s) included with the bot. Dynamic channel settings If you want to add a channel to your bot or change a channel's settings, you don't actually need to edit the config file. Eggdrop has built-in DCC commands that allow you to add/remove channels and change channel settings via the console. To add a channel, simply type .+chan #channel. Removing a channel is as simple as .-chan #channel. Channel settings are modified using the .chanset command. This works in different ways depending on whether you're changing a on/off switches such as autoop, dynamicbans, etc., or changing a channel option such as idle-kick. Below are some examples of how the .chanset command is used: .chanset #channel +enforcebans will enable the enforcebans option. .chanset #channel -dynamicbans +autoop will disable dynamicbans, and enable autoop. .chanset #channel chanmode +sntk green will change the channel's chanmode setting to "+sntk green". .chanset #channel idle-kick 60 will set the channel's idle-kick setting to 60. To view all current channel settings for a channel, type .chaninfo #channel. THE CHANFILE Because the bot cannot modify its own config file, channels added with the .+chan command and channel settings modified with the .chanset command need to be stored in a special file called the chanfile. You may remember specifying the chanfile in your bot's config file (e.g. set chanfile "mybot.chan"). The chanfile ensures any changes you make using the DCC commands will be remembered even if the bot is shut down and restarted. There is a downside to having a channel file. Whenever the bot starts, it will first read from its config file, followed by the chanfile. Any channel settings you've specified in the config file will be overwritten by those in the chanfile - if you make changes to a channel's settings in the config file, they will not take effect. In order to change a channel's settings, you have to use the DCC commands. This can often result in a channel's actual settings being out of sync with those specified in the config file. As a result, some people chose not to add channels in the config file at all, instead using exclusively the DCC commands for adding channels and modifying their settings. You can chose not to have a chanfile by setting it to "" in the bot's config file (e.g. set chanfile ""). This will allow you to make all changes to channel settings in the config file, but any changes you make using the DCC commands will not be remembered permanently by the bot. Remember to utilise Eggdrop's internal .help feature to learn more about all the different commands. Once you're familiar with all the basic Eggdrop functions and commands, find out how to enhance your Eggdrop.
  5. Eggdrop Few Tricks

    Some little tricks that you may or may not know about: 1. You can "lock" a user's info line by putting a '@' as the first letter. They won't be able to change it any more. 2. '.status all' will dump out virtually everything you have configured on your bot. 3. You can automagically make a ban sticky by adding a '*' as the first character in the ban reason. 4. You can modify Eggdrop's output in partyline and messages by editing core.english.lang in the language directory. 5. You can unlink all bots and clear out the botnet info from memory by using '.unlink *'. It erases all channel assocs and everything. 6. Tcl has a command 'info body <proc>' that will list the contents of a proc and 'info args <proc>' shows what you have defined as the parameters for the proc. 7. If you don't want your logfiles to be deleted after two days and don't want the bot to create a new logfile each new day, then set 'keep-all-logs' to 0 and 'switch-logfiles-at' to 2500 in your eggdrop config file to make it keeping one logfile all the time. REMEMBER: this is not recommended on high traffic channels. 8. You can use variables in your config file, since it's really just a normal Tcl file. For example, you can set 'userfile' and 'chanfile' to "yourbot.user" and "yourbot.chan" using the following method: set myvar "yourbot" set userfile "$myvar.user" set chanfile "$myvar.chan" 9. You can export parts of your config file to separate files. For example, if you have several config files which differ from themselves only by the nickname and the used servers, you can export them to an own file and link it with the 'source' Tcl command, similar to a script. The advantage of this is that you have to edit/upload only the small file instead of the big one. This technique is also useful if you want to maintain the same channel settings, etc across your botnet. 10. You can rename a builtin command by binding over it. To rename '.status' to '.report', you'd do: unbind dcc - status *dcc:status bind dcc m report *dcc:status The first line removes the builtin binding on '.status' and the second line binds '.report' to the builtin status function.
  6. Eggdrop v1.8.4 Stable Release

    Eggdrop v1.8.4 has gone STABLE. Hooray! The major changes are: - lots of work on the compile process for less-commonly seen systems (SunOS, DragonFly, etc), and making eggdrop more compiler-friendly in general - added and enhanced SSL/TLS warnings to make troubleshooting easier - raised the ban expiration limit from 1 year to 5 years, and added a new \%y field to +ban - lots of work on TLS bot links - improved/clarified botnet TLS documentation- go read it! - made TLS fingerprints persistent across a botnet after relinking - sterilized a LOT of small, lingering bugs. You can follow development and report bugs on https://github.com/eggheads/eggdrop Download Eggdrop v1.8.4 here
  7. Did you know that several free and open source control panels are available for your VPS? Managing multiple websites with a control panel on your VPS can be cumbersome, time consuming and complicated. To simplify the deployment of websites and apps, you can install a control panel app that will help you manage the critical components of your VPS. Most shared hosting providers offer their own web based administration panels. One popular, but costly solution is cPanel. If you manage your own VPS servers, working within an administration panel can streamline the process of performing administration tasks. Control panels remove the struggle of working via SSH while simultaneously being able to offer a silo for administration within a specific web property. Let's evaluate 3 of the top control panels for your VPS. VestaCP VestaCP is a free control panel that has been gaining a lot of momentum over the last couple of years. With a couple of hosts sponsoring their development, it has remained steady and shows no signs of going anywhere. Installation of this is simple. It can be installed on CentOS 5, 6, 7 as well as Debian 6, 7, 8 and even Ubuntu 12 – 15. These two commands will have your installation running: curl -O http://vestacp.com/pub/vst-install.sh bash vst-install.sh At the end of the installation process you will be provided with the details to log in. ISPConfig ISPConfig 3 is an open source hosting control panel for Linux which is capable of managing multiple servers from one control panel. ISPConfig is licensed under the BSD license. This control panel features powerful modules that administrate common server tasks. ISPConfig is only available for Linux and the website offers detailed installation instructions on how to rapidly get started with server environment you choose. http://www.ispconfig.org/ispconfig/download/ Webmin Webmin is a web-based interface for system administration for Unix. Using any modern web browser, you can setup user accounts, Apache, DNS, file sharing and much more. Webmin removes the need to manually edit Unix configuration files and lets you easily manage your VPS. The installation process is of Wedmin is trivial. Assuming you are working on a Ubuntu server, execute the commands needed to install the panel. First, you will need to install the repository by adding the following lines in your/etc/apt/sources.list: deb http://download.webmin.com/download/repository sarge contrib deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib You will then need to install the GPG key with which all the packages are signed: wget http://www.webmin.com/jcameron-key.asc apt-key add jcameron-key.asc The final step? Simply launch the 2 following commands to start the installation: apt-get update apt-get install webmin Once the process finishes, you will be able to connect to the panel using your browser at the following address: https://server-ip-address:10000 Remember to open port 10000 in case you should have a firewall installed. Did this tutorial help you out? Please let us know in the comments sections below.
  8. pisg

    Version 0.7.3


    Pisg - an abbreviation of the Perl the IRC Statistic Generator . The parser, which generates a nice html-stats user activity on a specific channel on IRC. It is used to generate log files.Supported formats: X-Chat, mIRC, mIRC6 , Eggdrops, bxlog for BitchX, irssi, virc98, dancer, Trillian, Grufti, mbot, winbot, zcbot, muh, energymech, ircII, psybnc, ircle, infobot, axur, bobot ++, oer , perlbot, Vision, pircbot, KVIrc , HydraIRC, sirc, moobot, supybot, blootbot, dircproxy. The only requirement thing: the Perl (and of course do the logs). More info: http://pisg.sourceforge.net/


  9. eggdrop-1.8.3.tar.gz

    Version 1.8.3


    The major changes are: - bugfixes related to SSL/TLS and botnets in particular - backwards-compatible syntax change to the addbot command (dcc and Tcl) to restore sanity when dealing with IPv6 addresses. - a new .resetconsole dcc command was added to reset your console flags to the defaults. - simplified botnet debugging, with the console modes +h/+g showing outgoing and incoming botnet raw traffic respectively. - significant work on many botnet features and bugs, to include additional granularity in botnet traffic console flags, improved logging, and some issues with SSL handshakes. - additional error/sanity checks for user inputs with various commands For the full list of changes see doc/Changes1.8. You can follow development and report bugs on https://github.com/eggheads/eggdrop


  10. Eggdrop v1.8.3 Stable Release

    The final release of Eggdrop version 1.8.2 is here! The major changes are: - bugfixes related to SSL/TLS and botnets in particular - Backwards-compatible syntax change to the addbot command (dcc and Tcl) to restore sanity when dealing with IPv6 addresses. - A new .resetconsole dcc command was added to reset your console flags to the defaults. - Simplified botnet debugging, with the console modes +h/+g showing outgoing and incoming botnet raw traffic respectively. - Significant work on many botnet features and bugs, to include additional granularity in botnet traffic console flags, improved logging, and some issues with SSL handshakes. - Additional error/sanity checks for user inputs with various commands You can follow development and report bugs on https://github.com/eggheads/eggdrop Download Eggdrop v1.8.3 here
  11. 1. Commands for +P users (partyline access) .addlog <text> Allows you to add a message to the eggdrops log if something needs explaining, such as an eggdrop conflict. It will include your handle. .away <message> Set you away on the party line only. .back Back from away on the partyline only. .botinfo Returns a line for each eggdrop on the botnet with version, uptime, etc. .bots Returns a list of eggdrops on the botnet. .bottree Returns a list of eggdrops whcih are linked (if there are any linked eggdrops). .channel <#channel> Returns a list of the users on that channel. .console <#channel> <+|-modes> Changes your console modes for that channel. .dob <your date of birth> Sets your birthday in your whois in the eggdrop. .echo <off|on> Turns the repeat of what you say in the party line to others as off/on. .email <your email addy> Sets an email addy in your whois on the eggdrop. .email none Removes your listed email in the eggdrop. .help Returns a list of commands. .help all Returns a longer list of commends. .help whois Returns a lengthy defined list of user/eggdrop flags. .help <command> Returns the explanation on the specified command. .info <#channel> <infoline> Sets your infoline in the whois in the eggdrop. .irl <name> Sets your real name in the whois in the eggdrop. .match <+|-flags> <#channel> Finds what matches your search on the eggdrop. .motd Returns the MOTD that you saw when you first connected in DCC with the eggdrop. .newpass <new password> Changes your password on the eggdrop. .nick <newnick> Changes your nickname in the eggdrop only. .notes erase <index|all> Deletes the specified notes. .notes index Returns a list of notes left on the eggdrop for you. .note <handle> <message> Leaves a note for that user. .notes read <index|all> Returns a list of notes. .quit [message] Disconnects you on the partyline only. .strip <modes> Allows you to strip certain modes in the partyline, such as ASCII, bold, color, underline, etc. .su <handle> Allows you to change your nickname in the partyline to one that is on the eggdrops access list, if you know their password. .trace <botnick> Returns a list of eggdrops between the one you are on and the one you traced, if you have eggdrops that are linked. .url <your URL> Sets a URL in your whois in the eggdrop. .url none Removes your URL in the eggdrop. .vbottree Returns a list of eggdrops which are linked (if there are any linked eggdrops) along with their version of eggdrop. .who Returns a list of users on that eggdrop. .whom Returns a list of users on the botnet (if the eggdrops are linked). .whois <handle> Returns the users flags and added hostmasks. 2. Commands for +O users (channel ops) .act [#channel] <action> Allows you to send an action (like the /me smiles command) to a channel as if the eggdrop performed the action. .+ban <hostmask> [#channel] [time] [reason] Sets a ban on that hostmask. .-ban <hostmask|index> Deletes a ban from the eggdrop banlist. .bans <#channel|*|all> Returns a list of bans on the eggdrop. .deop <nickname> [#channel] Deops (-o) the specified user, only if they do not have a +o on that channel in the eggdrops access list. .devoice <nickname> [#channel] Devoices (-v) the specified user, only if they do not have a +v on that channel in the eggdrops access list. .+exempt <hostmask> [#channel] [time] [reason] Exempts a user from kicks/bans .-exempt <hostmask|index> Removes a user from the exempt list. .exempt <channel|*|all> Returns a list of all who are exempt from kicks/bans. .+invites <hostmask> [#channel] [time] [reason] Invites are set the same way as bans above. .-invite <hostmask|index> Deletes a user from the invite list. .invites <#channel|*|all> Returns a list of users on the invite list. .invite <nickname> [#channel] Invites the specified user to the specified channel. .kick <nickname> [#channel] [reason] Kicks the specified user off of the channel. If no reason is given the default is 'requested'. .kickban <nickname> [#channel] [reason] Kicks and bans the user off the channel. If no reason is given the default is 'requested'. .msg <handle> <text> Allows a global +o/op (not a channel +o/op) to send private messages/queries through the eggdrop to users, as if the eggdrop sent the message. .op <nickname> [#channel] Gives the specified user temporary +o/op status in the channel specified. .resetbans <#channel> Resets the ban list so that any bans not in the eggdrops permanent ban list will be removed. .resetexempts <#channel> Resets the exempt list so that any bans not in the eggdrops permanent exempt list will be removed. .resetinvites <#channel> Resets the invites list so that any bans not in the eggdrops permanent invites list will be removed. .say [#channel] <message> Allows you to say something through the eggdrop to the channel. .stick <ban|exempt|invite> <hostmask|index> Adds the ban or exempt or invite permanently to the specified list. .topic <message> Changes the topic. .unstick <ban|exempt|invite> <hostmask|index> Removes the permanent status of the ban or exempt or invite and it then reverts to the time set in the eggdrops config-file. .voice <nickname> [#channel] Gives the specified user temporary +v/voice status in the channel specified. 3. Commands for +M users (channel masters) .adduser <handle|nickname> Creates a record for the specified added user. .chaninfo <#channel> Returns a list of all the channels modes set through the eggdrop. Most can be changed in DCC rather than in the eggdrops config-file. .chinfo <handle> <#channel> <info-line> Sets an info-line for that user. .+chrec <handle> [#channel] Adds an empty channel so that laston and userlines can be stored. .-chrec <handle> [#channel] Removes the stored channel record, which includes laston, userlines and flags. .deluser <handle> Deletes the specified user from the eggdrops records. 4. Commands for +N users (channel owners) .chanload Allows you to fix something you may have changed. It goes back to the file that was last saved. .chansave Saves the channel modes to a file when the eggdrop is rehashed or restarted. .chanset <#channel> <settings> Allows you to change most channel modes and settings. i.e. +nt or +seen +chan <#channel> Adds a channel to the list of channels the eggdrop will guard. .-chan <#channel> Removes a channel from the eggdrops channel list. .chpass <handle> <password> Changes the specified users password on the eggdrop. .die Kills the eggdrops connection and logs who performed this command. :( .jump <server> [port] The eggdrop parts the present server and joins the server that was specified. .loadmod <modulename> Loads a module. .module <modulename> Finds the module and returns stats on the requested module. .module <botnick> Returns a list of modules running on the specified eggdrop. .rehelp The eggdrop looks for new help commands and adds them. .servers Returns a list of servers in the eggdrops config-file that it uses to join the server. .set <variable> <value> Changes the variables that were set in the config-file. .set ban-time <#channel> Set the duration in for the ban in minutes before it is deleted. .unloadmod <modulename> Unloads a module. 5. Commands for +M users (global/botnet masters) .backup Creates a backup of the userlist, to the shell. .banner <message> Sends a message across the botnet. .binds <type|all> Displays a list of binds, with usage, that are being used by the eggdrops added tcl scripts. .boot <handle|botnick> Kicks someone off the partyline. Bot owners cannot be kicked :P .+bot <botnick> <IP:bot-listening-port> Adds an eggdrop to another eggdrops record. .-bot <botnick> Removes an eggdrop from another eggdrops record. .botattr <botnick> <+|-flag(s)> [#channel] Adds bot flags to another eggdrops record. .chaddr <botnick> <IP:bot-listening-port> Changes the info that was given in the .+bot info. .chattr <handle|botname> <+|-flag(s)> [blank for global|#channel] Adds/removes flags from a users record. .clearqueue <mode|server|help|all> Deletes information in the specified queue. .comment <handle> <comment> Adds a comment for the user that only botmasters and owners can view. .dccstat Returns a list of all connected to the eggdrop you are in, with some details attached. .debug Returns a list of memory allocations. Used only to find leaks in the eggdrop. .+host <handle|botnick> <hostmask> Adds a hostmask for the specified user. .-host <handle|botnick> Removes a hostmask for the specified user. .+ignore <hostmask> [reason] Adds that hostmask to the eggdrops ignore list so that anything sent to the eggdrops is simply ignored. .-ignore <hostmask|index> Removes that hostmask from the eggdrops records. .ignores * Searches the eggdrops records for all ignored users. .link <botnick> Links two eggdrops, so they have someone to chat with :) .relay <botnick> Changes your DCC chat to the one with the specified eggdrop. .rehash Reloads the config-file if you have changed a setting. .reload Reloads the last userlist if there was no .save done and ignores the changes if any were made since the last .save. .reset <#channel> Removes all the channel modes so that you can start over from the server records. .restart Restarts the eggdrop so that changes you may have made in the config-file will take affect. Works better than a .rehash. .save Saves the added/removed information to the shell. .status Returns the status of the channel and eggdrop. .stats all Returns a lengthy description of your eggdrops status. .unlink <botnick> Unlinks the eggdrop from the one specified. .+user <handle> <hostmask> Adds a user to the eggdrop record with one hostmask and no flags. .uptime Returns the duration the eggdrop has been online. .-user <handle> Removes a user from the eggdrops records.
  12. ADDUSER - creates a new user record for a user on the channel, using their current hostname (with no password and the default flags). DCC SYNTAX: adduser [!]<nickname> [handle] If the user is using a different nickname than the bot normally knows her by, you can specify their "handle" (the nickname that the bot remembers). If the bot already knows someone by that nickname, and the user on the channel doesn't have a bot record, then it does the equivalent of an 'ident' for that user - except that, again, no information is sent to the user telling them that anything was done. # Add a user using the standard hostmask <zeke> .adduser nick <bot> Added [nick] *! ident@*.host.com with no password. You can add a user with a static hostmask when using '.adduser' by prefixing their nick by '!'. # Add a user using a static hostmask, prefix their nick with a '!' <zeke> .adduser !nick <bot> Added [nick] *!ident@some.host.com with no password. Have fun.
  13. Editing the botchk file

    Editing the botchk file to automatically restart your eggdrop The botchk script and crontab are used to automatically restart the eggdrop if the shell/vps it's on reboots or if the eggdrop process is killed for some other reason. You can find the botchk file in the scripts directory (in the directory you installed the eggdrop). Newer versions of Eggdrop (from 1.3.24i) have a script included that automatically configures botchk and crontab for you. In telnet, simply switch to the scripts directory and type chmod 700 autobotchk then ./autobotchk <config> -dir /home/your_eggdrop_dir -noemail, where /home/your_eggdrop_dir is the directory you installed the eggdrop to and <config> is the name you chose for your config file. Otherwise, you can edit the botchk file and insert the required crontab entry manually. There are only four things you need to set in the botchk file, all of which are pretty self explanatory. Once you've edited the botchk file, you need to add an entry to your crontab. Here's the best method: 1) Your crontab line should look like: 0,10,20,30,40,50 * * * * /home/your_eggdrop_dir/scripts/botchk >/dev/null 2>&1 This will run the botchk script every 10 minutes, which checks that the eggdrop is running and restarts it if it isn't. You just need to change the /home/your_eggdrop_dir part to the correct path to the eggdrop on your shell/vps (type pwd to show this). Save the line in Notepad or some place where you can highlight and copy it from. 2) Type crontab -e. This should bring up the shell/vps editor (it will appear as a bunch of lines starting with the ~ character). 3) For vi, do the following - hit Ctrl-L, hit i, paste the crontab line you created earlier, hit Esc, type :wq! then hit Enter (if you make a mistake doing this, just hit Esc and start over). 4) For pico, do the following - paste the crontab line you created earlier, hit ctrl-X, hit Y when prompted to save, hit Enter when prompted for a filename. You can view your current crontab entries by typing crontab -l. To clear your crontab, use crontab -r (may be crontab -d on some shells/vps).
  14. 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 cool@modem36.ppp.yourisp.net, eggdrop will make your hostmask *!cool@*.yourisp.net. If you are a eggdrop 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 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!*@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 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!*@*.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 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 your@email.address.com < /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.
  15. A New home for Tcl Scripts Archive Read the news about the changes here. The new site is located at http://www.tclarchive.org, hosts the old tcl scripts from egghelp.org and is accepting new tcl scripts submissions. Good news, considering that slennox @ egghelp.org hasn't been active for quite some time and tcl scripts submissions were closed. The egghelp.org tcl archive was one of the web's premier repositories of Tcl scripts for Eggdrop, allowing you to search or browse hundreds of scripts that enhanced your bot's functionality. At last update 7 October 2014 it reached over 1743 hosted tcl scripts by 939 authors.
  16. A New home for Tcl Scripts Archive Read the news about the changes here. The new site is located at http://www.tclarchive.org, hosts the old tcl scripts from egghelp.org and is accepting new tcl scripts submissions. Good news, considering that slennox @ egghelp.org hasn't been active for quite some time and tcl scripts submissions were closed. The egghelp.org tcl archive was one of the web's premier repositories of Tcl scripts for Eggdrop, allowing you to search or browse hundreds of scripts that enhanced your bot's functionality. At last update 7 October 2014 it reached over 1743 hosted tcl scripts by 939 authors.
  17. BlackToolS 2.5

    Minor text fixes: spelling and grammar mistakes. The download links were already updated with the fixes. Enjoy! * DONT FORGET: to report your newly found bugs to us!
  18. BlackTools.es.lang.tcl

    Version .2.4


    SPANISH LANGUAGE for Blacktools 2.4 Translation provided by Cadaver @ NationCHAT.Org

    2.00 EUR

  19. BlackTools 2.5 Release

  20. Eggdrop v1.8.2 Stable Release

    Eggdrop version 1.8.2 is here! The major changes are: - CBC mode option for blowfish (only relevant for Tcl scripts, thanks to Cizzle for the significant patch) - Starting Eggdrop with -nt gives full access on the terminal now to simplify debugging - Eggdrop won't quit with the error message "CAN'T WRITE TO TEMP DIR" anymore (temp dir is optional for filesys/transfer mod) - The Tcl command getuser can now retrieve a list of key/value pairs to get all settings for a user - Portuguese language file added (thanks TheMythPT) - Fixed an issue with ./configure --with-ssllib, which prevented users from using a non-standard OpenSSL installation location You can follow development and report bugs on https://github.com/eggheads/eggdrop Download Eggdrop v1.8.2 here
  21. Eggdrop v1.8.0 Stable Release

    It looks like the Eggdrop community is getting an early (or perhaps very, very late) Christmas present! They proudly announced the stable release of Eggdrop 1.8.0! This effort has taken years of hard work, and over 15,000 commits adding more than 50,000 lines of code. Among literally hundreds of smaller fixes, the biggest changes are SSL and IPv6 support. These additions mean extra config file settings to use them, so while your old config file will still work, you may want to consider using the new eggdrop.conf included with this release. Speaking of the config file, they also brought back an old feature: eggdrop-basic.conf. This file is a simplified version of the standard eggdrop.conf targeted towards new users to make the first run a little less daunting. While this file is good for a quick start, we still strongly recommend you use the full eggdrop.conf to take advantage of all the features of Eggdrop. Also all TCL scripts written for v1.6 should still function with the v1.8 series of Eggdrop. While the core functionality of most 3rd party modules should still work, many are hard-coded to only run on a v1.6 Eggdrop. For a list of major changes and advice on upgrading from 1.6.x, check out the NEWS-1.8.0 file included within the Eggdrop source. Download Eggdrop v1.8.0 here
  22. Eggdrop v1.8.1 Stable Release

    After two release candidates, the final version of Eggdrop version v1.8.1 is now ready. The major changes between 1.8.0 and 1.8.1 are: Autobotchk: Added functionality improvements, allowing special characters to be used in botnicks (and hence filenames), and made it able to deal with split up configs that source further files. who linkedbot output: Truncates long channel listings appropriately. eggdrop.conf: Update source code to match defaults given in Eggdrop configuration file. Timer drifts: If your bot really gets frozen longer than 60 minutes, it now shows times longer than 60 minutes. ./configure: Added an options summary at the end so you see which Tcl version was used, and whether it found IPv6 and SSL files OpenSSL: A new version of OpenSSL broke our OpenSSL detection (the hexstr2buf function) and we fixed that. Versioning: Moved previously hard-coded version strings to version.h and update them via misc/setpatch instead of misc/addpatch. This also fixes inconsistencies in setting the internal version integer. Bugs: A lot were cleaned up! For the full list of changes see doc/Changes1.8. You can follow development and report bugs on https://github.com/. Download Eggdrop v1.8.1 here.
  23. Fail2Ban is a simple script designed to scan log files for repeated failed login attempts and to ban IP addresses that make too many failures. Commonly that’s a brute force attempt to find correct password combination to login to a server via SSH. Step 1 – Login to your server via your favorite SSH client. Windows users can simply use Putty, it is free, small, portable and awesome. If you’ve disabled root login, then simply login with the username you setup then type “su” followed by entering your root password. Step 2 – Now issue this command syntax to install fail2ban on your server: You may firstly need to update your apt (not necessary but you may): | apt-get update then this command is the one to install fail2ban | apt-get install fail2ban screenshot: Step 3 – Now you have to setup Fail2ban’s configuration. By default, Fail2ban configuration has included many of possible services that may need the protection. Before you make changes to default config file, you have to make a copy first. Issue following command: | cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local It should look like this Step 4 – The command above copies “jail.conf” file to “jail.local” which you can make some changes to the config there. Now edit that file using our favorite text editor, Nano: | nano /etc/fail2ban/jail.local It should look like this.. Step 5 – Now make some changes (if you wish and if you need to) in the first section of the config. The first section called “DEFAULT” which is covering all basic rules that fail2ban will follow. The main important part is “ignore ip”. You can add your own IP address there so in case if you forgot the password you won’t be banned for trying some combinations no matter how many times you try. It means by adding your IP in the white list you can avoid accidentally ban yourself. Also do not forget to set “bantime” which rules how many seconds a banned user will still been locked out. Default value is 600 seconds or 10 minutes. You can adjust that value as you wish but you better raise the value because most of brute force bots will simply move on to the next target once banned by the server. Below “bantime” line is “maxretry”. This line defines how the amount of incorrect login attempts that a single IP may have before it gets banned for the length of the ban time you’ve defined. Default value is “3” but you can lower that value to “2” or “1”. The lower is better but make sure you white-listed your IP already in the “ignore ip” line above. The next line is “backend” which you can simply leave its value as “auto”. Now move to another line, “destemail”. In this line you can define to which email address all alerts will be sent. Simply change root@localhost to your own personal email address. But you have to make sure that your server has a working mail server already to be able to send outgoing email. Step 6 – Now move to the next section which is “Action”. Well, you can simply leave those lines as it is if you don’t really sure. All default value should be adequate for fail2ban to work correctly. Now you have to move a little bit down below and find the [ssh] section. You also don’t have to change that section. Its default values indicating that SSH protection is currently enabled / ON. You can change “enabled = true” to false if you want to turn OFF the protection. You can change the “port = ssh” line to the custom port number your SSH connection is designated. For instance, you’ve changed default SSH port from 22 to 2200, then change it to “port = 2200” Once done editing, hit Control+O to save then Control+X to exit Nano editor screen. Step 7 – That’s it. Now to make sure Fail2ban loads your newly defined config, simply do a restart. Issue this command: | service fail2ban restart Q: I rebooted the server, does it starts automatically? Yes, Fail2ban service will automatically start each time your server reboots. That’s it.
  24. Configuring IPv6 on your VPS

    All these examples assume an IPv6 subnet of 2001:DB8:1000::/64. You'll need to update them with the subnet that you have been assigned. We'll be using 2001:DB8:1000::100 as the main IP address to assign. We'll also be using 2001:19f0:4009:2001::1234 as a secondary IP address we're configuring. Adding a secondary IP is not necessary, but shows the process you'd use if you wanted multiple IPv6 addresses. Important Note: If you add an IPv6 subnet to an existing machine, you must restart the server via the control panel before IPv6 will work. Restarting via SSH or similar is not sufficient. IPv6 would not work at all until the server has been restarted. This does not apply if you've selected IPv6 during the initial server deployment. Windows: netsh interface ipv6 set global randomizeidentifiers=disabled netsh interface ipv6 add address interface="Local Area Connection" address="2001:DB8:1000::100/64" netsh interface ipv6 add address interface="Local Area Connection" address="2001:19f0:4009:2001::1234/64" CentOS: In /etc/sysconfig/network-scripts/ifcfg-eth0 add the following lines: IPV6INIT="yes" IPV6ADDR="2001:DB8:1000::100/64" IPV6_AUTOCONF="yes" IPV6ADDR_SECONDARIES="2001:19f0:4009:2001::1234/64" If you have IP forwarding enabled (if you're using your server as a VPN or similar), you'll need to add the following to /etc/sysctl.conf: net.ipv6.conf.all.accept_ra=2 net.ipv6.conf.eth0.accept_ra=2 The default settings here (which is 1), prevents IPv6 from working properly when IP forwarding is enabled. You can check if IP forwarding is enabled by running "sysctl net.ipv4.ip_forward". Debian/Ubuntu: In /etc/network/interfaces add the following lines: iface eth0 inet6 static address 2001:DB8:1000::100 netmask 64 up /sbin/ip -6 addr add dev eth0 2001:19f0:4009:2001::1234 If you have IP forwarding enabled (if you're using your server as a VPN or similar), you'll need to add the following to /etc/sysctl.conf: net.ipv6.conf.all.accept_ra=2 net.ipv6.conf.eth0.accept_ra=2 The default settings here (which is 1), prevents IPv6 from working properly when IP forwarding is enabled. You can check if IP forwarding is enabled by running "sysctl net.ipv4.ip_forward". FreeBSD: In /etc/rc.conf add the following lines: rtsold_enable="YES" ipv6_activate_all_interfaces="YES" rtsold_flags="-aF" ifconfig_vtnet0_ipv6="inet6 2001:DB8:1000::100 prefixlen 64 accept_rtadv" ifconfig_vtnet0_alias0="inet6 2001:19f0:4009:2001::1234 prefixlen 64"
  25. ZNC is an advanced IRC network bouncer that is left connected all the time so that an IRC client can disconnect or reconnect without losing the chat session. In this tutorial, we'll compile ZNC with the web admin module installed. Installation Packages First of all, and as always, we'll update the package cache. sudo apt-get update Next, we'll install some dependencies required to compile ZNC. sudo apt-get install libssl-dev libperl-dev pkg-config build-essential Compile and install ZNC Download the latest release of ZNC: cd /usr/local/src sudo wget http://znc.in/releases/znc-latest.tar.gz Extract ZNC from the tarball, and then enter the source directory: sudo tar xf znc-latest.tar.gz cd znc-*/ At this step, you can set ZNC's installation directory by adding the --prefix=<yourdir> option. But for now, we'll install it system wide: ./configure We'll compile ZNC and install it with the following commands. To speed up the process, you may add -j n to the first make command, where n is the number of cores / vCPUs on your server. sudo make sudo make install This may take a few minutes, depends on your machine's configuration. Configuration It is important not to run web-facing apps under root. So we'll create a new user for ZNC. adduser --disabled-password znc Now switch to znc. su znc - cd ~ Create ZNC's config file under znc: /usr/local/bin/znc --makeconf ZNC will ask us some questions in order to create the config file. The first one is important; note your input because you will connect to the ZNC daemon using that port. We'll enter 6697 now - that's the default port for IRC with SSL / TLS. [ ?? ] What port would you like ZNC to listen on? (1025 to 65535): 6697 It is strongly recommended to enable SSL listening instead of the plain-text (i.e. insecure) scheme. Would you like ZNC to listen using SSL? (yes/no) [no]: yes Next question is regarding IPv6. That actually depends on your needs. If your home network is IPv6 enabled, it's recommended to enable. We'll just leave the default option there. [ ?? ] Would you like ZNC to listen using both IPv4 and IPv6? (yes/no) [yes]: <press Enter> Now it'll prompt us about two global modules, partyline and webadmin. They're self-explanatory, and we'll need to enable them. [ ?? ] Load global module <partyline>? (yes/no) [no]: yes [ ?? ] Load global module <webadmin>? (yes/no) [no]: yes User creation. Enter your desired username and password for the user, then confirm it. Note that the password will not be echoed. [ ?? ] Username (AlphaNumeric): Doe [ ?? ] Enter Password: <password> [ ?? ] Confirm Password: <password> Grant the user admin permissions: [ ?? ] Would you like this user to be an admin? (yes/no) [yes]: yes Then, your IRC network options. Set it on your own. Here's an example: [ ?? ] Nick [Doe]: Doe [ ?? ] Alt Nick [Doe_]: Doe_ [ ?? ] Ident [Doe]: DoeIdent [ ?? ] Real Name [Got ZNC?]: Jane Doe [ ?? ] Bind Host (optional): server.hostname [ ?? ] Number of lines to buffer per channel [50]: 50 [ ?? ] Would you like to clear channel buffers after replay? (yes/no) [yes]: yes Enable these modules: [ ?? ] Load module <chansaver>? (yes/no) [no]: yes [ ?? ] Load module <controlpanel>? (yes/no) [no]: yes [ ?? ] Load module <perform>? (yes/no) [no]: yes [ ?? ] Load module <webadmin>? (yes/no) [no]: yes Now we may setup the IRC network that ZNC will connect to. [ ?? ] Would you like to set up a network? (yes/no) [no]: yes We'll use #ubuntu on Freenode for example. Network (e.g. 'freenode' or 'efnet'): freenode Information about these network modules prompted are here. [ ?? ] Load module <chansaver>? (yes/no) [no]: yes [ ?? ] Load module <keepnick>? (yes/no) [no]: yes [ ?? ] Load module <kickrejoin>? (yes/no) [no]: yes [ ?? ] Load module <kickrejoin>? (yes/no) [no]: yes [ ?? ] Load module <nickserv>? (yes/no) [no]: yes [ ?? ] Load module <perform>? (yes/no) [no]: yes [ ?? ] Load module <simple_away>? (yes/no) [no]: yes Set the server we'll connect to: [ ?? ] IRC server (host only): irc.freenode.net [ ?? ] [irc.freenode.net] Port (1 to 65535) [6667]: 6697 [ ?? ] [irc.freenode.net] Password (probably empty): [ ?? ] Does this server use SSL? (yes/no) [no]: yes [ ** ] [ ?? ] Would you like to add another server for this IRC network? (yes/no) [no]: no And the channel we'll join: [ ?? ] Would you like to add a channel for ZNC to automatically join? (yes/no) [yes]: yes [ ?? ] Channel name: #ubuntu [ ?? ] Would you like to add another channel? (yes/no) [no]: no Finish the configuration and launch ZNC: [ ?? ] Would you like to set up another user? (yes/no) [no]: no [ .. ] Writing config [/home/znc/.znc/configs/znc.conf]... [ >> ] ok ... ... [ ?? ] Launch ZNC now? (yes/no) [yes]: yes Yay. ZNC is up and running!