IRC-Junkie.org – IRC News

All about Internet Relay Chat

DAL.net adds "Text CAPTCHA" to registration

DAL.net adds – and is probably the first network to do this – a “text CAPTCHA” to its nick-registration process.

DAL.net Network Logo

DAL.net Network Logo

Their news announcement says that they want to ensure that a nickname and a channel should always be able to be registered first by a human and not a bot.

They do that in response to a trend they noticed where they reportedly have “seen increases in bots getting nicks and channels, holding them, and never releasing them” and continue to say that it’s “not fair to the average person that a botnet gets a nickname before a human does”.

According to the announcement the questions are simple and will be changed weekly – an article in their knowledgebase provides an example of a question that might get used in the registration process:

For example, if the question is “Mark’s name is?”, you would answer:
/NickServ REGISTER <password> <email> mark

The knowledgebase article states that they – for obvious reasons – won’t provide a list with all possible questions and answers but if you should have further questions you’re welcome to /join #DALnetHelp and ask them there.

  Copyright secured by Digiprove

DALnet releases Bahamut IRCd 1.8.6

After more than 2 years of silence the DALnet Coding Team released a new version of Bahamut, an IRCd mainly used on DAL.net.

First being released as version 1.8.5 there was a bugfix-release shortly thereafter as a bug has been found in channelmode +c which sometimes not only prevented control-characters as bold and underlined being sent but also stripped legitimate messages that contained certain arabic and hebrew characters.

We took the time to ask Epiphani – the Coding Teams Team-Leader – a few question about his IRCd and the history of it:

- The last release, 1.8.4, was over 2 years ago – why did it take so long for 1.8.5 (and now 1.8.6) to be released?

It’s mostly been two reasons:

1. We didn’t really have a lot of minor things we wanted to work on.

Bahamut has been stable and effective for several years, and while there is enhancements that we’d like to implement, those enhancements are more major changes than they are small updates.

We did have a few fixes come through the pipe, such as security fixes and minor other fixes (such as updated x64 support), and we decided to roll them into a patch release.

2. Life gets in the way of open source development sometimes.

At present, the team is mostly idle as life has started eating most of their time. I’ve had a few changes in my life recently that have allowed me to put more time into Bahamut once again, so I’m hoping we can revive some development.

We’ve also changed some of our processes (including a move from subversion to git) so we’re hoping to get more involvement from the community in the future.

- The list of changes introduced with this release does look small compared to the ones introduced with 1.8.4 – what, in your opinion, are the most important ones?

Mostly the security updates.

For example, we removed zlib from the distribution and made it an external dependency, due to security updates from the zlib people – we didn’t want to have to release every time zlib has an issue.

There were also a few fixes for “IP leaks” where hub IPs could be shown to normal users in certain edge cases.

- Are there any changes that are noticeable on the user side of things?

Nope, not in this release.

- When did the development on Bahamut start and why?

I believe the project kicked off sometime in late 1998, with the first public release in 1999. I can’t really remember, that was a good while ago.  :)

The Bahamut project came about due to some of the performance concerns around the former DALnet ircd, Dreamforge.

Back in 1999 DALnet was growing very fast, and the hardware we were running on wasn’t terribly fast.

We needed to be able to support over 6000 clients on a 250Mhz machine, and Dreamforge simply didn’t perform to those levels. Once we rolled out Bahamut, we started seeing much better performance.

I believe somewhere in 2001 we hit our record with around 45,000 clients on a single 900Mhz AMD Duron machine with 512 megs of ram.

- Is there anything you’d like to mention?

We’re always looking for contributors to Bahamut.

We have a wishlist of features, including ipv6 and other such things, that anyone is welcome to code up and provide patches for to the dalnet-src [at] dal.net mailing list.

We are mostly interested in people with the initiative to bounce ideas around on the mailing lists and go off and code!

The complete list of changes between 1.8.4 and 1.8.6 is below:

- Fixes for x64 – this is a combination of Kobi’s work and my own.
- Fixed m_part() and m_quit() to ignore part/quit reasons from squelched users.
- Fixed compiler errors with gcc4.
- Changed a debug message that could leak servers’ IPs to ADMIN_LEV. Thanks key!
- Fix configure tests for zlib removal.
- This patch is intended to mark SVSHOLDs as SBAN_SVSHOLD to stop them from being removed by a kill -HUP
- Fix several small issues where IPs would be displayed when they shouldnt be, from Kobi (kobi [at] dal.net)
- Do not display uplink of ulined servers, from Kobi (kobi [at] dal.net)
- Fix slight errors in m_who argument parsing, from kobi (kobi [at] dal.net)
- Do not display warnings about juped servers attempting to commit, from Kobi (kobi [at] dal.net).
- Fixed m_invite to honor umode +R and silence restrictions.
- Two small rwho fixes to option parsing, from Kobi (kobi [at] dal.net)
- Add hooks for several events
- Remove zlib from the distribution – rely on the library provided by the system.
- Fix msg_has_ctrls() so it doesn’t block non-control characters.

Bahamut IRCd can be downloaded from here.

Thanks go to Epiphani for the short interview and the wants-to-stay-anonymous tipster for the tip! :)

DALnet Disbands Testnet Team

“We’ve just disbanded the DALnet testnet team and integrated all of the application evaluation functions into the routing team as they were before. This is a step to streamline the application process and adapt to current needs and change in workload” DALnet’s Ahnberg announced yesterday on the DALnet mailinglist.

The Testnet Team has been testing new server applications and handled questions asked by applicants. It was formed to handle the large amount of applications coming in. “… a lot of server applications was in movement and we felt we needed to give more attention to them all. It was also a time when we got a huge bunch of less serious applicants that would require in depth analysis of approvals of ISPs, checkup on the admins background, etc. This all took time and we felt it was most appropriate to have a separate team to handle most of the application steps,” Ahnberg told to IRC-Junkie in a reaction.

As the network is turning back into quieter waters, the situation is rolled back to the former state. In the end, many of the same people will however be involved in the application process, as Ahnberg explains: “Many of the testnet members are already routing members, so we would not lose valuable experience.”

DALnet AKILL's FDCservers Colocation Center

Recently, DALnet decided to AKILL all customers from FDCservers, a co-location company quite a few shell providers have their server located at.

Ahnberg, admin at DALnet, explained to IRC-Junkie in a reaction; “I’ve heard that the abuse from them over the years has been extremely large, and that the staff working with this and the chaos their users and subcompanies (shellproviders renting rackspace, I guess) cause to our network. It is a very bothersome and time-straining thing to have to handle for our colleagues.”

Psyxakias, admin of the SharkTECH shellcompany explains; “We helped by managing DALnet abuses (in the last 2 months) in order to provide even better connectivity to all FDC/Shark clients by connecting to DALnet IX network. Although we managed all abuse reports (even the ones without logs), DALnet proceeded to the AKILL (which now say it was planned in the last 6 months) and now declines to talk to anyone further than FDCservers.”

DALnet stopped this cooperation because of the way logs were treated by the shell companies. DALnet’s Jim explains on a FDCservers’ forum; “It is an accepted rule of abuse handling that upstream providers (in this case SharkTech) DO NOT pass on, verbatim, abuse reports to thier clients. This is accepted practice across the internet and serves to protect both those making the complaint and the upstream provider.”

At this point no contact has been made between DALnet and FDCservers in order to resolve this issue, with the thread on FDCservers’ site quite lively on the subject.

edit: Psyxakias contacted me and pointed me out to an error I made in the article, SharkTECH is not a shellcompany: “We provide dedicated servers (not even virtual servers) & managed hosting”, Psyxakias explained. Excuses for the inconvenience.

DALnet acts upon XXX password sharing

Since a few days channel managers of XXX password channels on DALnet have been directed to read this page. “You have been directed to this page because you are listed as founder on a channel which has been reported to us as a location where passwords for adult sites are traded”, the page starts.

Only channel managers of channels which have been found actively trading XXX passwords are directed to this page. DALnet’s AUP section III disallow the exchange of private information such as logins. In a reaction to IRC-Junkie DALnet admin Ahnberg pointed out that it is not specifically XXX passwords which are being targeted. “I just emphasize that we’re not doing things to censor particular content, we’re acting on a general level. i.e. just because there were a bunch of XXX-pass-trading channels alerted due to this we do not single them out. We treat everyone equally. If we were to find channels who spread login information for sites with info for bird-watchers, we would act on that too.”

We asked Ahnberg if the closure means disallowing all access to a channel, or just removal of services. “AFAIK the channels have not yet been acted upon, but yes, they will be entirely blocked in this case since their sole purpose has been to trade personal information of individuals without their consent” Ahnberg explains.

“We’re not actively monitoring or “hunting” things down”, Ahnberg explains. “We usually act on reports or when something stick out.”

Thanks to Garp who initially pointed me out to this.