So what does the future hold for WyldRyde?  I have spent a lot of time thinking about this topic and have gone back and forth in my head several times, but I’ve come to a decision that I feel is best.  Before I go on and explain the plans, let me just say, I came to this decision after thinking about what would be most fair to the users of the network.  I do not have the time anymore to devote towards running a full service IRC network and I do not want to let anyone down in the future — I don’t think that would be fair to people who may want to host their channels on WyldRyde.

So here is what I plan to do:

WyldRyde will remain a (limited) public IRC network.  

What does that mean?  It means WyldRyde will be open for anyone to connect to but will not be open for new channel registrations.  We will allow channels registered before November 25th, 2011 to remain as active channels on WyldRyde if they so choose.  However, we will not be allowing any new channels to be registered.  If you wish to keep your channel on WyldRyde that is perfectly fine.  If not, that’s fine too and we will help you move your channel over to the network of your choice if you need help.

I plan to focus my time in the channel and communities of #besttechie and #textual.

WyldRyde will only be providing limited support to channels.

Again, I do not have the time to devote to providing full service support to every channel.  So if you decide to keep your channel, you should have a good understanding of IRC and the commands.

WyldRyde has plans to lower server capacity in the future.

We have servers paid for through some of 2012 and into 2013, however, when the contract’s are up we are currently thinking about dropping 1 or 2 of the servers.  This of course depends upon the user base at the time, however, it should be known and factored into your decision when it comes to keeping your channel on WyldRyde or not.  If you are willing to donate a server in the future we may consider it at that point in time.

Regardless of whether you decide to keep your channel or not we would love to have to stick around in any of the channels that remain.  You are welcome to join #besttechie, #textual, #textual-offtopic, and #thelounge.  All four channels are great for talking about all types of topics from tech to movies to general chat.

Thanks for riding WyldRyde! We hope to see you guys around.

Bug Fixes, Better IPv6 Support

First and foremost, the decision to update our Unreal installations was based predominantly on a known bug with older versions of the IRCd where CGI:IRC (the mechanism that allows services like Mibbit and our own QWebIRC installations to serve as a proxy to connect you to the network) was extremely flawed with IPv6.  While this in itself was very critical in our ongoing effort to implement IPv6 support, there were also a number of outstanding issues with the version of Unreal we were running (albeit most of which very minor), so it made a great deal of sense for us to go ahead with this update to better our stability and performance.

Extended Ban Options

As part of our updates, users can now take advantage of new extended ban options (very similar to the word-blocking ban system that we loaded last month) that allows for them to better control their channels.  Below is a brief explanation of these extended ban options:

The use of “~c” in a ban or channel ban exception will allow a channel owner to disallow or explicitly allow members of another channel into their channel.  For example, if I wanted to disallow users from joining my channel (#mike) if they were in the #help channel, I would use the following command;

/mode #mike +b ~c:#help

Likewise, I could opt to ban all users from my channel by default and add an exception to only allow users inside the #help channel to join my channel by using the following command;

/mode #mike +be *!*@* ~c:#help

I can also add a mode character to a ban (or exception) statement so that only members of certain channel statuses could join my channel.  For example, I could add an exception to always allow half-ops and above from the #help channel into my channel;

/mode #mike +e ~c:%#help

Channel operators can now place bans on user “real names” in order to ban users of certain clients, scripts, and IRC embed services (those that use a static “real name”) from a channel.  For example, Mibbit sets the “real name” value of all of its users to “http://www.mibbit.com”.  To ban all users with this real name value, I would use the command;

/mode #chan +b ~r:http://www.mibbit.com

Likewise, because my “real name” value is always set to “Mike Mansell”, you could ban me from your channel – regardless of the nick, ident, or hostname I was using – by using the following command;

/mode #chan +b ~r:mike_mansell

As you can see, I replaced the space with an underscore (“_”).  Because underscores match both spaces and actual underscores, this ban would disallow anyone with the real name of “Mike Mansell” or “Mike_Mansell” from joining the channel.  Of course, you can also use this as a channel ban exemption as well simply by replacing the “+b” with “+e”.

Last but not least, the addition of the “~R” extended ban-type, while only of use for ban exemptions, allows you to ban or exempt users only if they are registered and identified.  For example, if you wanted a ban exemption to only apply to me when I was identified, you would use the command;

/mode #chan +e ~R:Mike

Sure, this could very well be used as a ban as well, but it really would be somewhat pointless.  On a side note, channel owners may wish to ponder using the “restricted” option with ChanServ to kick and ban any users who attempt to join a channel without being on the VOP/HOP/AOP/SOP list or a channel owner.

Implementation of “~” and “&” Characters for Channel Owners and Admins

The implementation of “~” and “&” channel-mode characters for channel owners (mode +q) and channel administrators (mode +a) has likely been one of the most requested features here on WyldRyde over the last couple of years.

While the old version of Unreal that we were running did indeed support these characters in channels the option had to be configured during the compiling stage and was not something that we saw as justifiable to re-compile and re-start our servers.  However, with the popularity of this request this feature was enabled as part of our updates.

Now, channel administrators (members of the “SOP” class in ChanServ, or users with level 10 access in a standard non-XOP level configuration) are represented with the “&” character instead of simply the “@” character given to normal channel operators.  Likewise, channel owners (either the person who registered/inherited a channel or a user who used the owner password to identify as the channel owner) will now receive “~” characters in their respective channels.

Ident Verification

For a bit of extra precaution, we have also enabled ident checking in our new configuration.  Our recent implementation of this setting attempts to verify the “username” or “ident” (not to be confused with nickname) with an identd server on the client’s computer in an ultimate goal to validate the identity of users connecting to WyldRyde.

While this is a great feature to validate users, the fact of the matter is that many users do not have identd services running on their computers or shells, and many of those who do have firewall configurations that block us from validating the ident.  This, however, isn’t a big deal as users with un-validated idents simply have their idents prefixed with the “~” character (not to be confused with the channel mode character assigned to owners).

I myself do not have an ident daemon running on my personal computer, so even though my client is configured to use the ident/user “mike” (which would later become part of my hostmask “mike@wyldryde.org”), my ident is changed to “~mike” when connecting and my hostmask becomes “~mike@wyldryde.org.”

For those of you wishing to have hostmasks without the “~” in your ident, you can join the #help channel and request that a virtual host with a virtual ident (an entire virtual hostmask instead of a only a virtual hostname) be assigned to your registered nick.

As always, if you have any questions or notice anything that we’ve missed we ask that you don’t hesitate to contact us in the #help channel.

As part of these updates, WyldRyde will be restarting Unreal on all of our servers, meaning that there will be but a few minutes of downtime.  Because we have been working to make this update as smooth as possible the actual downtime for any given server should only be a few minutes.

We apologize for any inconvenience this may cause but assure you that this update is well worth the short downtime.  Any questions or concerns regarding this update can be directed at our #help channel.

G-Rated Channel Mode

First and foremost, the WyldRyde staff maintains an extensive list of bad words that are deemed to be inappropriate for friendly communities.  While we do not force any filters on any channels or configure such filters to be enabled automatically, channel owners and operators have the ability to censor the bad words on this list by setting channel mode “+G” (think “G-Rated”).  When this mode is in place, all bad words on our list are automatically replaced with “<censored>” in the channel.

BotServ Auto-Kicks

Additionally, users who opt to use our services bots have the option to configure “badwords” and “kick” options to configure a list of channel-specific bad words for which users will be automatically kicked for saying.  To do this, one must first have a services bot (through BotServ) assigned to their channel, as is explained in the “How do I add a services bot to my channel?” portion of the channel registration walk-through.

Once that is all set, a channel owner can add bad words with the following command;

/bs badwords #channel add word {position}

Of course, in this example you would replace “#channel” with your channel and “word” with the word you wanted to block.  While specifying the “position” option is entirely optional, not specifying this parameter will detect your specified “word” value as a bad word even if it is part of another word.  For example, if you blocked the word “car” in your channel without specifying a “position” value, the word “carton” would be deemed as a bad word as well.

On the flip side, if you specify “start” as your position value, only words starting with “car” would be detected bad words.  In our case, the word “carton” starts with “car”, so it indeed would be classified as a bad word.  Additionally, if you use a position value of “end”, only words ending with a specific set of characters would be caught and our “carton” example would not be seen as a bad word.

To tell BotServ to automatically kick users for using “bad” words, use the following command;

/bs kick #channel badwords on {ttb}

As always, “#channel” will need to be replaced with the name of the given channel.  Additionally, the optional parameter “ttb” will specify how many times a user can be kicked before they are banned from the channel for foul language.

Note: You can enable and disable “badword” kicking as often as you want without loosing the list of words you have configured with BotServ.

Word-Blocking Channel Mode

Last but not least we’ve recently loaded the “Text/Word Extended Ban” module onto all of our IRC leafs, giving channel owners yet another option for blocking words on their channels.

This particular module does not utilize its own mode, but rather adds the “~T” flag onto the channel ban (“+b”) mode to specify that it is a text block instead of a normal user join block.  In this following example, we are going to block the word “car” in a given channel.

/mode #channel +b ~T:block:car

With this mode in place, a user who attempted to use the word “car” in the channel would not be able to send their message.  However, “carton” would still be allowed.  To better control this, you can use the wildcard character (“*”) in your specified word.  Setting a word ban on “car*” would block the word “carton”, while a word ban on “*car” would block the word “racecar” and “*car*” would block messages with words that contained “car” anywhere in them.

Additionally, you can replace “block” in the parameters with “censor” to replace specified bad words with “<censored>” instead of blocking the message altogether.

Be sure to keep in mind that channels can use any combination of these offerings, and as always you’re more than welcome to pop into our help channel if you have any questions.

As IPv6 is a complete overhaul of the Internet Protocol, users with only an IPv4 connection cannot communicate with other users and servers that operate only on IPv6 and vice versa.  Again, this is not a huge issue as of yet because there are very few people or servers that have IPv6-only connections.  In fact, it has been estimated that the number of users who have IPv6 connections (even those who have both IPv4 and IPv6) is less than one percent.  But as the number of IPv4 addresses diminishes and the number of IPv6 users increases, this is becoming a growing concern for many.

On top of this, the vast number of IPv6 addresses available means that each and every compatible device will be able to have its own IPv6 address, eliminating the need for NAT (Network Address Translation) behind routers.  Because of this, the widespread implementation of IPv6 will lead to speedier connections with less latency as well.

Here at WyldRyde we’re always taking concern in how our network will fare with the latest technological innovations, and IPv6 is definitely not an exception.  So how are we handling the implementation of IPv6?

As of right now, Nikon.WyldRyde.org has an IPv6 address assigned to and configured for it.  This means that users connecting to Nikon.Wyldryde.org, IRC.WyldRyde.org, or our newly-formed IPv6.WyldRyde.org round-robin (over an IPv6 connection, of course) will connect to WyldRyde via IPv6 if their client is configured (or capable) of doing so.

But one server isn’t enough.  All of our other servers are currently in data-centers that are in the process of rolling out IPv6 support and we currently estimate that all servers will be IPv6-ready by the end of this year.  And as each server gains IPv6 support, the appropriate AAAA (IPv6) DNS record will be added to the IRC.WyldRyde.org round-robin, in addition to our IPv6-only IPv6.WyldRyde.org round-robin.

Those currently on IPv6 connections are more than welcome to connect via the new protocol.  Of course, we’re not phasing out IPv4 support anytime soon as it’s still a standard on the Internet.

We have ultimately opted to implement qwebirc because we believe that it is one of the most stable and well-supported clients out there, and its long history with larger IRC networks has time-proven it enough for us to comfortably implement it for our users.

Being AJAX-based qwebirc is able to run within any modern web browser – inclusive of the ones commonly used on mobile phones and tablets – all without requiring the use of the somewhat resource-intensive Adobe Flash platform.

Having said this, WyldRyde will not be completely abandoning Flash-based IRC access to our servers.  We will continue to host the lightIRC client for those who have existing embeds on their websites and we will continue to run the Flash policy daemon (on the flash.wyldryde.org round-robin, port 8001) for lightIRC and other Flash-based clients to be able to connect.  However, from this point forward qwebirc will be the preferred and supported embed for those looking to implement our chat services on their websites.

In preparation for our qwebirc implementation, we recently installed and loaded the ns_ajoin module which allows our users to automatically be joined to channels they select whenever they connect and identify to our services.  What this means is that one can now use whatever IRC client (be it web-based or desktop-based) to connect to WyldRyde without having to worry about synchronizing, moving, or duplicating their client’s auto-join list.

To connect to our servers using qwebirc you can use the chat page here on our website or connect directly to irc.wyldryde.org in your web browser for a full-screen alternative.  Additionally, we have updated our chat embed generator so that channel owners can generate new embed codes for their sites.

As always any questions or comments regarding our new qwebirc implementation can be directed to our help channel where we will do our best to assist you.

A screenshot of the qwebirc client connecting to the WyldRyde IRC Network without a pre-specifified channel

A screenshot of qwebirc connecting to a pre-specified channel on the WyldRyde IRC Network

/ns ajoin add #channelnamehere

For example, if you wanted to add #besttechie to your auto join list you would type: /ns ajoin add #besttechie

If you want to remove a channel from your auto join list, it’s just as easy. To delete a channel from your auto join list use the following command (below).

/ns ajoin del #channelnamehere

For example, if you wanted to delete #besttechie from your auto join list you would type: /ns ajoin del #besttechie

As always, if you have any questions, feel free to drop by our #help channel.

WyldRyde makes it dead-simple for your to create a chat-room for your community or group.  This step-by-step guide will show you how to go about registering a channel, adding a BotServ bot to it, and giving selected users voice and operator status.

What is required to register a channel?

In order to register your channel, you will need a registered nick on WyldRyde.  In short, the command to register your nick is “/ns register password email”, and you would replace “password” and “email” with your desired password and email address, respectively.  For a more in-depth guide to registering your nick, please reference my previous tutorial.

How do I go about registering a channel?

Once you are connected, registered, and identified, registering a channel is a simple two-step process.  First, you will want to use the /join command (“/join”  followed by a space and your desired channel name) to join the channel you with to register.  Remember that all channel names are prefixed with the pound sign (“#”), so your channel name should be in the form of “#ChannelName”.

Upon joining your channel, you should be the channel operator.  In clients such as mIRC and Textual, your channel operator status will be represented with the “@” symbol.  Other client such as XChat represent channel operator status with a green emblem.  Once you have assured that you have operator status, you can go about registering the channel with ChanServ.

The actual ChanServ registration process is rather straight-forward.  The command that you will want to enter is:

/cs register #channel password description

For the “#channel” variable, you will want to use the name of the channel that you joined and hold channel operator status in.  The “password” variable is simply a secure password as chosen by you.  This password can later be shared with a designated channel co-owner in order to allow another user to have the same level of channel access that is typically limited to the person who registered the channel.  Lastly, “description” needs to be replaced with a simple description (spaces allowed of the channel).  Below is a sample registration command:

Once you have submitted the command, ChanServ should send you a notice stating that the channel has been successfully registered to your name.  Additionally, ChanServ will apply mode “+r” to the channel to signify that it has been registered and  will give you mode “+q” in the channel to identify you as the channel’s owner.

Note: Even though you are the owner of a channel, you will not have the “~” or “&” symbols that are sometimes uses by other networks to symbolize a user’s owner or admin status in a channel.  WyldRyde uses the “@” symbol for all channel owners (+q), admins (+a), and operators (+o).  Despite the fact that you do not have the “~” or “&” symbols you are still the channel owner because you have the “+q” mode.

How do I add a services bot to my channel?

Adding a services bot allows you to use the commands available for BotServ in order to maintain your channel in a more simplistic fashion.

To add a bot to your channel, you will first need to select a bot name from the list of available bots (114 available as of the time of writing).  This list can be seen by typing “/bs botlist” in the text area within your client.

Once you enter this command, you should receive a list of bot names.  This list will have not only the names of the bots, but their idents and virtual hosts as well.  The list will be similar to the one shown below:

After you have selected a name from the list, assigning the bot is as simple as entering the following command:

/bs assign #channel bot

Be sure to replace “#channel” with the channel you wish to assign the bot to (it must be a channel that you own) and “bot” with the name you selected from the list.

Note: If you are interested in getting a custom bot name, please join the #help channel (“/join #help”) and ask to speak with a Services or Network Administrator about acquiring one.

Upon sending this command, you should receive confirmation from BotServ that the bot was successfully assigned.  Additionally, you will know that you executed the command correctly when you see that the bot you requested as joined your channel.

One thing that I typically do is enable “fantasy” commands within BotServ.  This allows your channel ops to take advantage of in-channel command such as “!kick” in order to simplify the channel maintenance experience.  To enable this, use the command “/bs set #channel fantasy on”, ensuring that you replace “#channel” with the name of your channel.

How do I assign access levels to other users?

One of the great things about ChanServ is that it allows you to give registered users access levels within the channel, and allows for these access levels to be associated with the user’s identity.  This means that you do not have to worry about re-voicing or re-oping a user whenever he or she enters your channel, as you can have services do it automatically.

The basic command for assigning an access level to a user is: “/cs LVL #channel add nick”.  In this command, you must replace “#channel” with your channel name and “nick” with the user who you are assigning an access level to.  Additionally, you must replace “LVL” with a three-digit code from below to tell ChanServ exactly what level of access that you want said user to have.  The following table shows the three-digit code, the modes that it will give the user, and an idea of what the user will be able to do with the given level of access.

Once you submit the command, you will receive confirmation from ChanServ that everything went through successfully.

If you wish to give someone co-owner status in your channel, you must give them the password that you set during the channel registration process.  Then, they will need to use the command “/cs identify #channel password”, replacing “#channel” with the channel name and “password” with the password you set.

Note, however, that you should only give the founder’s password to people that you really trust, as a co-owner has full control over the channel’s settings and can even go as far as removing your owner status, regardless of the fact that you originally created the channel.

What if I have more questions?

As always, you are encouraged to join the #help channel (“/join #help”, or visit using the web-chat) if you have any questions.  A staff member or helper will be more than willing to help!

Registering your online handle (known as your “nick”) on WyldRyde gives you a great number of benefits that will ultimately make your experience on WyldRyde that much better.

What are the benefits of registering?

Some of the benifits from having a registered nick include:

• The ability to protect your nick
  Registering your nick ensures that you are the only one able to use it.  This eliminates the need to worry about someone stealing your nick or impersonating you on IRC.
• The ability to register channels
  Registered  WyldRyde users are able to register channels (also known as chat rooms) of their own on WyldRyde.  Registration is necessary to do this because each channel registration needs to be associated with a registered nick.  Obviously, this cannot be done if you do not register.
• The possibility of becoming voiced or op’d in channels
  Often times when a user proves themselves to be trustworthy in a channel, the owner of said channel will give them “status” in the channel.  User statuses are associated with nicks, and without registering you will make it impossible for a channel owner to “promote” you within the room.
• Qualification for a VHost
  WyldRyde allows for registered users to request a virtual hostname (also known as a VHost) to mask the hostname assigned to them by their ISP.  Again, this is something that is associated with the users WyldRyde identity, meaning that in order to obtain a VHost the user must be registered.

How do I register?

Registering your nick is by no stretch of the imagination a difficult process, and in this tutorial I will walk you through said process step by step.

First off, you’re going to need an IRC client.  There are a number of desktop clients that you can download and use on your computer, however you can also use our web-based chat client if you cannot or do not wish to install software onto your computer.

Upon connecting to WyldRyde (use “/connect irc.wyldryde.org” in your client if you’re not using the web-based chat), the first thing you will want to do is change your nick to something that you’d like to register.  I always recommended putting thought into your nick selection, because even though you can change it down the road, it’s good practice to keep a consistent name.  Once you have pondered your nick selection, use the /nick command (type “/nick” followed by your desired nickname).  This will change your nickname.

Once you have changed your nick, you’ll want to register it through NickServ – the nickname services bot on WyldRyde.  To do this, you need to type “/ns register” followed by your desired password and email address.  It’s best practice to use a strong password that would be difficult (if not impossible) for another user to guess.  While we do not check the validity of email addresses, I always recommended that you enter your real email address, because this will allow us to assist you with password resets in the event that you forget your password.  Below is an example of the registration command.

How do I identify?

Of course, once you register your nick you will need to identify upon returning to WyldRyde.  If you are using the web-based chat client, identifying is as simple as providing your password in the log-in box.  The same can also be said for many modern-day IRC clients such as XChat (Windows and Linux) and Textual (Mac OS X).

However, if you have a client that does not have a built-in option for handling NickServ passwords, you can simply use the /identify command (“/indentify” followed by your password) to identify with NickServ.  To automatically identify, you may also look into your client’s “connect commands” options to automatically send the identification command upon connecting to WyldRyde.

What if I need help?

If you find that you require assistance in registering your nick, feel free to stop by the #help channel on WyldRyde (/join #help), or connect via our web-based chat client.  For a complete list of commands available through NickServ, visit the NickServ commands page.

Hi all,

This is very embarrassing…

We found out that the Unreal3.2.8.1.tar.gz file on our mirrors has been
replaced quite a while ago with a version with a backdoor (trojan) in it.
This backdoor allows a person to execute ANY command with the privileges of
the user running the ircd. The backdoor can be executed regardless of any user
restrictions (so even if you have passworded server or hub that doesn’t allow
any users in).

It appears the replacement of the .tar.gz occurred in November 2009 (at least
on some mirrors). It seems nobody noticed it until now.

Obviously, this is a very serious issue, and we’re taking precautions so this
will never happen again, and if it somehow does that it will be noticed quickly.
We will also re-implement PGP/GPG signing of releases. Even though in practice
(very) few people verify files, it will still be useful for those people who do.

Safe versions
==============

The Windows (SSL and non-ssl) versions are NOT affected.

CVS is also not affected.

3.2.8 and any earlier versions are not affected.

Any Unreal3.2.8.1.tar.gz downloaded BEFORE October 11 2009 should be safe, but
you should really double-check, see next.

How to check if you’re running the backdoored version
======================================================
Two ways:

One is to check if the Unreal3.2.8.1.tar.gz you have is good or bad by running
‘md5sum Unreal3.2.8.1.tar.gz’ on it.
Backdoored version (BAD) is: 752e46f2d873c1679fa99de3f52a274d
Official version (GOOD) is: 7b741e94e867c0a7370553fd01506c66

The other way is to run this command in your Unreal3.2 directory:
grep DEBUG3_DOLOG_SYSTEM include/struct.h
If it outputs two lines, then you’re running the backdoored/trojanized version.
If it outputs nothing, then you’re safe and there’s nothing to do.

What to do if you’re running the backdoored version
====================================================
Obviously, you only need to do this if you checked you are indeed running the
backdoored version, as mentioned above. Otherwise there’s no point in
continuing, as the version on our website is (now back) the good one from
April 13 2009 and nothing ‘new’.

Solution:
* Re-download from http://www.unrealircd.com/
* Verify MD5 (or SHA1) checksums, see next section (!)
* Recompile and restart UnrealIRCd

The backdoor is in the core, it is not possible to ‘clean’ UnrealIRCd without
a restart or through a module.

How to verify that the release is the official version
=======================================================
You can check by running ‘md5sum Unreal3.2.8.1.tar.gz’, it should output:
7b741e94e867c0a7370553fd01506c66 Unreal3.2.8.1.tar.gz

For reference, here are the md5sums for ALL proper files:
7b741e94e867c0a7370553fd01506c66 Unreal3.2.8.1.tar.gz
5a6941385cd04f19d9f4241e5c912d18 Unreal3.2.8.1.exe
a54eafa6861b6219f4f28451450cdbd3 Unreal3.2.8.1-SSL.exe

These are the EXACT same MD5sums as mentioned on April 13 2009 in the initial
3.2.8.1 announcement to the unreal-notify and unreal-users mailing list.

Finally
========
Again, I would like to apologize about this security breach.
We simply did not notice, but should have.
We did not check the files on all mirrors regularly, but should have.
We did not sign releases through PGP/GPG, but should have done so.

This advisory (and updates to it, if any) is posted to:

http://www.unrealircd.com/txt/unrealsecadvisory.20100612.txt

Hope you’ll all continue to support UnrealIRCd.

- –
Bram Matthys
Software developer/IT consultant syzop@vulnscan.org