zeke

TCL scripter
  • Content count

    46
  • Joined

  • Last visited

  • Time Online

    19h 56m 50s

Everything posted by zeke

  1. 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.
  2. pisg

    Version 0.7.3

    100 downloads

    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/

    Free

  3. 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:
  4. eggdrop-1.8.3.tar.gz

    Version 1.8.3

    134 downloads

    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

    Free

  5. 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
  6. 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.
  7. 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.
  8. 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.
  9. 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).
  10. 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.
  11. 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.
  12. 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.
  13. 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!
  14. BlackTools.es.lang.tcl

    Version .2.4

    1 download

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

    2.00 EUR

  15. BlackTools 2.5 Release

    COOL! LET'S GO TESTING!
  16. 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
  17. 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
  18. 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.
  19. 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.
  20. 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"
  21. 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!
  22. In this tutorial, you will learn how to add a web interface to your Linux VPS. The instructions here were tested using Ubuntu 12.04. Ajenti is an open source, web-based, lightweight control panel for Linux servers. It offers a simple, yet powerful graphical interface to perform most of the actions that are required to configure and keep your server up-to-date. If you want a simple, yet stable control panel with some eye candy, then try Ajenti on your VPS. Setup repositories Connect to your server using SSH as the root user. Download the latest package files. apt-get update Import keys and add the Ajenti Repository. Pay attention, this is important to prevent installing infected packages. wget http://repo.ajenti.org/debian/key -O- | apt-key add - Add the APT repository to to your sources.list file. echo "deb http://repo.ajenti.org/ng/debian main main ubuntu" >> /etc/apt/sources.list Install Ajenti Update the package sources again, then install the Ajenti package. apt-get update apt-get install ajenti Start Ajenti with the following command. service ajenti restart Now you can access the Ajenti panel by navigating to the following URL in a web browser. Replace [SERVER_IP] with the IP address of your VPS. https://[SERVER_IP]:8000/ If you are unable to access this URL, try opening the TCP port with the following command. iptables -A INPUT -p tcp --dport 8000 -j ACCEPT You will be presented with an invalid SSL certificate error. It is safe to proceed. Next, you will see a login screen. You can login with any UNIX username, such as root. At this point, you are inside the Ajenti panel. Navigate around the panel to start using some of its primary features, such as processor usage, memory usage, SSH over the web browser, cron job setup, firewall configuration, file system load, and more!
  23. There are several ways of logging into a server over SSH. Methods include password login, key-based login, and two-factor authentication. Two-factor authentication is a much better type of protection. In the event that your computer gets compromised, the attacker would still need an access code to login. In this tutorial, you will learn how to set up two-factor authentication on an Ubuntu server using Google Authenticator and SSH. Step 1: Prerequisites An Ubuntu 14.04 server (or newer). A non-root user with sudo access. A smart phone (Android or iOS) with the Google Authenticator App installed. You can also use Authy or any other app supporting TOTP based logins. Step 2: Installing Google Authenticator Library We need to install the Google Authenticator Library module available for Ubuntu which will allow the server to read and validate codes. Run the following commands. sudo apt-get update sudo apt-get install libpam-google-authenticator Step 3: Configure Google Authenticator for each user To configure the module, just run the following command. google-authenticator Once you run the command, you will be asked certain questions. The first question would be: Do you want authentication tokens to be time-based (y/n) Press y and you will get a QR code, secret key, verification code, and emergency backup codes. Take out your phone and open the Google Authenticator app. You can either scan the QR code or add the secret key to add a new entry. Once you have done that, note down the backup codes and keep them safe somewhere. In case your phone gets misplaced or damaged, you can use those codes to login. For the remaining questions, press y when asked to update the .google_authenticator file, y for disallowing multiple uses of same token, n for increasing time-window, and y to enable rate-limiting. You will have to repeat Step 3 for all of the users on your machine, otherwise they won't be able to login once you are through with this tutorial. Step 4: Configure SSH to use Google Authenticator Now that all users on your machine have set up their Google authenticator app, its time to configure the SSH to use this authentication method over the current one. Enter the following command to edit the sshd file. sudo nano /etc/pam.d/sshd Find the line @include common-auth and comment it out like below. # Standard Un*x authentication. #@include common-auth Add the following line to the bottom of this file. auth required pam_google_authenticator.so Press Ctrl + X to save and exit. Next, enter the following command to edit the sshd_config file. sudo nano /etc/ssh/sshd_config Find the term ChallengeResponseAuthentication and set its value to yes. Also find the term PasswordAuthentication, uncomment it, and change its value to no. # Change to no to disable tunnelled clear text passwords PasswordAuthentication no Next step is to add the following line to the bottom of the file. AuthenticationMethods publickey,keyboard-interactive Save and close the file by pressing Ctrl + X. Now that we have configured the SSH server to use the Google Authenticator, its time to restart it. sudo service ssh restart Try logging back into the server. This time you will be asked for your Authenticator code. ssh user@serverip Authenticated with partial success. Verification code: Enter the code that your app generates and you will be logged in successfully. Note In case you lose your phone, use the backup codes from Step 2. If you lost your backup codes, you can always find them in the .google_authenticator file under the user home directory after you login via console. Conclusion Having multiple factor authentication greatly improves your server's security and allows you to help thwart common brute force attacks.
  24. Introduction Easy Hosting Control Panel (EHCP for short) is a free and open source hosting control panel that can be used to host websites, create emails, sub domains, and FTP accounts easily using a web browser. It is written in the PHP programming language and provides built-in support for Nginx and PHP-FPM. Some of the EHCP features include: Open source and easily customizable. Manage DNS, domains, sub domains, FTP, MySQL, Email. Password protect domains. Support SSL, disk quota, domain alias, domain redirect. Backup and restore functionality. Supports unlimited user accounts, email accounts, and FTP accounts. Prerequisites A newly deployed Ubuntu 16.04 server instance. A non-root user with sudo privileges setup on your server. A static IP address of 192.168.15.110 configured on your system. As you're reading, replace this with the main IP of your server. Step 1: System update First, update your system to the latest stable version by running the following command: sudo apt-get update -y sudo apt-get upgrade -y sudo reboot Step 2: Install EHCP Download the latest version of the EHCP installation package. You can download EHCP from their official website. For example: wget http://ehcp.net/ehcp_yeni.tgz Once the download has completed, extract the downloaded file with the following command. tar -zxvf ehcp_yeni.tgz Next, change the directory to ehcp and run the install.sh script to install EHCP. cd ehcp sudo ./install.sh During the installation, read each step carefully and follow the instructions. The installer will install all of the required packages such as Apache, MySQL, Postfix and PHP. You will also need to provide some information to configure the different services and set the admin passwords. The installation can take up to 60 minutes depending on your internet speed. Upon a successful installation, you will see the following output: ehcp install finished up to now. we are continuing on simplifying the install process. sorry for any inconvenience. you can contact email/msn: info@ehcp.net you may join us in developing this control panel. You may visit http://www.ehcp.net You may support by donating cash, buying a pro license, doing php coding, html design, graphic design... You may support by donating free dedicated or virtual servers for this project... CURRENTLY WE NEED A DEDICATED SERVER WITH 8 CORE, 8GRAM, 500G hdd at least (or, you may consider to buy a pro license or donate..) ehcp : Finished all operations.. go to your panel at http://yourip/ now... Step 3: Access EHCP dashboard It's time to access the EHCP dashboard. Open your web browser and type the URL http://192.168.15.110. On the main page, click on the link that reads "Click here for the control panel on your server". Enter your login credentials. The default username is admin and the password is the one you setup during the installation. If you haven't set a password, use the default password of 1234. Congratulations! You have successfully installed EHCP on Ubuntu 16.04 server.
  25. Using a sudo user to access a server and execute commands at root level is a very common practice among Linux and Unix Systems Administrator. The use of a sudo user is often coupled by disabling direct root access to one's server in an effort to prevent unauthorized access. In this tutorial, we will be covering the basic steps for disabling direct root access, creating a sudo user, and setting up the sudo group on CentOS, Debian, and FreeBSD. Prerequisites A newly installed Linux server with your preferred distribution. A text editor installed on the server whether it's nano, vi, vim, emacs. Step 1: Installing sudo Debian apt-get install sudo -y CentOS yum install sudo -y FreeBSD cd /usr/ports/security/sudo/ && make install clean or pkg install sudo Step 2: Adding the sudo user A sudo user is a normal user account on a Linux or Unix machine. Debian adduser mynewusername CentOS adduser mynewusername FreeBSD adduser mynewusername Step 3: Adding the new user to the wheel group (optional) The wheel group is a user group which limits the number of people who are able to su to root. Adding your sudo user to the wheel group is entirely optional, but it is advisable. Note: In Debian, the sudo group is often found instead of wheel. You can however manually add the wheel group using the groupadd command. For the purpose of this tutorial, we will use the sudo group for Debian. The difference between wheel and sudo. In CentOS and Debian, a user belonging to the wheel group can execute su and directly ascend to root. Meanwhile, a sudo user would have use the sudo sufirst. Essentially, there is no real difference except for the syntax used to become root, and users belonging to both groups can use the sudo command. Debian usermod -aG sudo mynewusername CentOS usermod -aG wheel mynewusername FreeBSD pw group mod wheel -m mynewusername Step 4: Making sure your sudoers file is setup properly It is important to ensure that sudoers file located in /etc/sudoers is setup properly in order to allow sudo users to effectively use the sudo command. In order to accomplish that, we will view the contents of /etc/sudoers and edit them where applicable. Debian vim /etc/sudoers or visudo CentOS vim /etc/sudoers or visudo FreeBSD vim /etc/sudoers or visudo Note: The visudo command will open /etc/sudoers using the system's preferred text editor (usually vi or vim). Start reviewing and editing below this line: # Allow members of group sudo to execute any command This section of /etc/sudoers often looks like this: # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL In some systems, you may not find %wheel instead of %sudo; in which case, this would be the line under which you would start modifying. If the line starting with %sudo in Debian or %wheel in CentOS and FreeBSD is not commented out (prefixed by #), this means that sudo is already setup and is enabled. You can then move to the next step. Step 5: Allowing a user that belongs to neither the wheel nor the sudo group to execute the sudo command It is possible to allow a user that is in neither user groups to execute the sudo command by simply adding them to /etc/sudoers as follows: anotherusername ALL=(ALL) ALL Step 6: Restarting the SSHD Server In order to apply the changes you made to /etc/sudoers, you need to restart the SSHD server as follows: Debian /etc/init.d/sshd restart CentOS 6 /etc/init.d/sshd restart CentOS 7 systemctl restart sshd.service FreeBSD /etc/rc.d/sshd start Step 7: Testing After you have restarted the SSH server, log out and then log back in as your sudo user, then attempt to execute some testing commands as follows: sudo uptime sudo whoami Any of the below commands will allow the sudo user to become root. sudo su - sudo -i sudo -S Notes: The whoami command will return root when coupled with sudo. You will be prompted to enter your user's password when executing the sudo command unless you explicitly instruct the system to not prompt sudo users for their passwords. Please note that is not a recommended practice. Optional: allowing sudo without entering the user's password As previously explained, this is not a recommended practice and is included in this tutorial for demonstration purposes only. In order to allow your sudo user to execute the sudo command without being prompted for their password, suffix the access line in /etc/sudoers with NOPASSWD: ALL as follows: %sudo ALL=(ALL:ALL) ALL NOPASSWD: ALL Note: You need to restart your SSHD server in order to apply the changes. Step 8: Disable direct root access Now that you have confirmed that you can use your sudo user without issues, it is time for the eighth and final step, disabling direct root access. First, open /etc/ssh/sshd_config using your favorite text editor and find the line containing the following string. It may be prefixed with a # character. PermitRootLogin Regardless of the prefix or the value of the option in /etc/ssh/sshd_config, you need to change that line to the following: PermitRootLogin no Finally, restart your SSHD server. Note: Do not forget to test your changes by attempting to SSH into your server as root. If you are unable to do so, this means that you have successfully completed all the necessary steps. This concludes the tutorial.