• What was this project? A quick overview.
• The project in detail: download the dissertation including the conception and implementation steps along with the source codes.
• A list of similar projects offering IRC bot lending on Undernet.

Before going into the core aspects of this project, it is important to quickly set some definitions and unfold some concepts.

• IRC stands for Internet Relay Chat and is a protocol for a real time chat network, defined by the RFC 1459, and updated by the RFC 2810, 2811, 2812 and 2813. This network is architectured around the client/server concept:

• The IRC protocol offers private messaging system to allow individual communication between 2 users (1:1), and chat rooms for communications between one and many (1:many) and many to many (many:many).
• The vast majority of IRC networks propose the chat service for free: the servers are maintained by volunteers and hosted for free on high speed networks of companies like providers, or administrations like universities.
• In order to moderate and administer the chat room, there are 2 levels of privileges: users and operators.
• The first user joining a chat room creates it, and therefore is granted operator privileges. One becomes operator by joining - if and only if - the chat room was empty before his join.
• An operator can grant or remove this privilege.
• If the last operator leaves a non-empty chat room (with normal users still in it), it becomes opless; hence non-administrable.
• Also, a vast majority of IRC networks propose a chat room registration service for free (i.e.: a robot on a chat room), in order to grant the operator status to the chat room owner (and the administrators he nominates) when they return.
• We have to make a difference between 2 types of clients:
• Regular : a human using a chat software.
• Robot : demon process hosted on a server and connected to an IRC network in order to perform there a set of predefined actions, triggered via commands (some requiring authentication). Robots usually present these characteristics:
• Store in a file the list and configuration of the chat rooms it has to join and a user database (login/password) with their access level.
• Open a port (accessed with telnet) to listen to instructions for administration purposes.
• Can be connected to a robot network around a hub robot (creating a botnet) to centralize the data.

• As we can observe, the IRC network is architecured in a chain. When this chain is broken (figure above), the network is said to have split. This situation can last hours (sometimes requiring human input), and the potential causes are multiple (congestion, attack, crash …). In such situations where the network is split in (at least) 2 independent networks, users connected to it face risks and discomfort.
• Even on the example of a registered chat room, only the side of the IRC network’s registration service will be administrable; the chat rooms on the other side(s) will have to wait for the split to end to become fully functional once again.
• Another discomfort come from “illegal” groups who take advantage of this weaken state of the network to take-over some chat rooms (using network attacks). The irony is that such attacks are often realized using flood techniques that can keep on making the split situation worse by adding congestion.

Possible solution : change the current architecture to a distributed IRC network; allowing as a side effect an optimal handling of the bandwidth (please note that on the current situation, each server has to handle the overall IRC network load!).

• On top of this IRC layer lacking reliability at user’s level, the goal of this project is to propose a curative solution, in complement of the official association in charge of registering the chat rooms.
• The Loufiz project delivered its service on the Undernet IRC network http://www.undernet.org/. Some figures about this IRC network:
• 120.000+ simultaneous users.
• ~40 servers in 13 countries.
• 3rd biggest chat network.
• In order to find out the type of solution to develop, a study of the different needs that the solution has to match has been made.

• Simple and user friendly to use:
• Some users are 10 years old.
• Few have technical knowledge.
• IRC is for most a place to have fun, and not stress about issues.
• Flexibility.
• Fast: sometimes the official registration process proposed by the IRC network can take up to 1(one) month.
• Reliability: users’ should be able to administrate their chat room at all times; so the operator status has to be kept and restored to legitimate chat room administrators when they return.
• Security granted via encrypted authentication.
• Simultaneous access.
• Users’ have different nationalities, so ideally the solution should be available in several languages.
• A human side, for support and advices.
• Free of charge.

• Simple and user friendly to use:
• Being an administrator of the project should require a will to help, more than technical knowledge.
• Should not replace human, but provide a synthesis at decisional nodes and process the results of these decisions.
• Automation of the flows in order to limit the repetitive tasks.
• Security and encryption: passwords and confidential data will be transferred.
• Monitoring: ways to supervise and anticipate.
• Maximal transparency towards the IRC network.
• Not bringing the situation from bad to worse by overloading the IRC network, this would increase the chances of splits.
• Independency towards the technological choices made, in order to be able to swap for one technology to another.
• Because the service is free of charge, it has to keep the costs as low as possible.
• Self-protection:
• Delimitation of the service offered.
• Registration of the identity of the users, through logs, in order to be able to provide tracks in case of abuse.
• Eventually being able to ban (blacklist) chat rooms who have proven being abusers.

• Main interests: administration, setup.
• This is the visible part of the service on IRC: robots are lent and placed on the chat room of the user requesting it.
• Use only : for security reasons, the administration port is filtered (prevent attacks of type buffer overflow targeted on our servers).
• Installed in a distributed architecture (continued in 3.1).
• Technology chosen:eggdrop, because this is a mature program (first release in 1993) published under the GPL license. It is also very modular: can evolve with TCL (Tool Common Language) scripts published by a very active community.

• Main interests : conception and development.
• Transparently orchestrate the flows (continued in 3.2).
• Transfers are encrypted through a SSL (Secure Socket Layer) channel.
• Multilingual dynamic administration platform: data and robots administration via mouse clicks.
• Ease of use and user friendliness.
• Guiding rail to avoid incorrect operations to be processed, and break down the flows in transactions respecting the ACID attributes (Atomicity Consistency Isolation Durability).
• The displayed texts are split into “language packs”, making the set of possible languages users’ can choose from, easy to change and modular.
• Displays the conditions of service to accept, in order to register.
• The registration process on the website binds to the freshly created user ID, it’s corresponding IP and a timestamp.
• Online knowledge base via a FAQ (Frequently Asked Questions) of more than 50 entries.
• Technology chosen:Apache, PHP, MySQL, because they are reliable and free for non commercial use.

• Main interests : conception and development.
• Keep the botnet synchronized with the database, that gets updated through the website (continued in 3.3).
• Update the database with information fetched from the botnet for monitoring purposes.
• Technology chosen:Perl.

• Main interests : Management, organisation.
• They are the human aspect of the project, welcome and help users to best use the service and the resources available to them.
• 7 Administrators are split on several time zones: 1 Romania , 2 France , 3 Canada , 1 USA .

• As highlighted in the introduction, each robot of the botnet has its own set of files for the chat rooms configuration and users’ data. In our case, the centralized data in the hub robot, come from the database, and is the result of the user input during the registration and/or the administration step. At the conception step of this solution, we can either choose to:
• Have all the data kept in a single place and develop a module for the hub robot to have its data and configuration loaded from the database instead of the file as standard. If an advantage is that there would be no identical data stored at 2 different places (avoiding possible conflict and synchronizing problems), this module will however be specific for the robot software chosen (here eggdrop), and any change to another software will require to port this application. Another aspect to consider is that the hub robot could face some problems if for any reason he cannot contact the database (i.e. network failure, database crash …).
• Have identical data being stored at 2 different locations, running the risk mentioned above (and taking preventive steps for it – see 3.3), but having the botnet as an independent part of the solution.
• As we can see, each of the choice comes with its set of advantages and inconvenients.
• Choice made : double storage. Here our main aim is to increase reliability, and in the in case of a database (for example), even if there will be no possible update on the botnet, the global users’ data will still available for the robots (and therefore usable by the users through IRC) and frozen as it was, at the time of the crash. Please note that the crash issue has to be taken as a high probability: the service will be free of charge, so we cannot afford to buy servers; in our case, most of our servers are made of old hardware given away. One aspect of the challenge is to take this point under account to deliver at the end a reliable solution.

• Conceptual view of a botnet :

• Distributed architecture. Redundant service: 3 robots are lent per chat room, each of the robot being run on a separate host, and connected at all times to a different IRC server than the 2 others.
• The list of the IRC servers is divided into 3 “equal” groups, depending on their geographical distance from our servers hosting the robots.

• Transparency: the port 113 (identd) is open, as requested by the IRC network staff; allowing up to 4 IRC connections per IP.
• The logical robot group concept (see above) is expanded to our 5 hosts, with 4 robots running per host, and gives the conceptual view here under.

• The robots ask at connection time to not receive all the discussions of the chat rooms, but only the messages specifically sent to them. As a side effect:
• It limits the quantity of bandwidth used by this solution.
• Increase the privacy of the protected chat rooms.
• Limit the risks of flood based attacks targeting our robots.
• The RFC 1459 defines the maximum number of chat rooms an IRC client can join to 10. So here is our maximal capacity of 6 logical groups * 10 = 60 chat rooms.

As briefly explained above, the website is the user friendly platform to administrate the lent robots. It therefore orchestrates transparently the flows while matching some standards of security.

• The traffic between a user’s web browser and our web server is encapsulated in SSL and bound to a session. A session permits to keep the user’s preference such as the language chosen (in our case English or French) and his authentication data.
• The conditions of service are publicly displayed, along with a FAQ and a list of other robot lending associations.
• All the operations performed can be represented as flows (see figure under). Examples of possible operations are given after, both for the users’ and administrators’ sections.

• Users’ section.
• Registration, leading to the creation of a new user ID.
• Request of service with the possibility to follow-up the request.
• Having a forgotten password sent by mail.
• Data administration :
• Of the user ID.
• Of the chat room where robots have been lent (depending on privileges – 4 levels available).
• Information/monitoring of the lent robots.
• Having the lent robots removed from the chat room, or give the chat room to another user ID.
• Administrators’ section.
• Overview of the resources’ availability.
• Review the users’ requests of service, by proofing that they match the conditions of service.
• Global data administration (depending on privileges) :
• Users ID and registered chat rooms.
• Blacklisted chat rooms.
• Add/remove a web link (to a partner website or to another robot lending association).
• Add/remove an administrator.
• In depth monitoring of the botnet, proposing possible solutions depending on the issue (see 3.3).
• Complete reconstruction of the botnet’s data according to the database (see 3.3):
• The recorded userlist.
• Proof and correct the good configuration of the chat rooms.

• Update SQL => Botnet.
• Incremental. When a change is made on the database through the web interface, a description of these changes is stored (in “botnet language”) into a table acting as buffer between the database and the botnet. In parallel, a Perl program is set to run at regular interval at system’s level to drag these updates from the database into the botnet.
• Complete. In very exceptional cases of lack of synchronization, a complete rebuilt of the botnet’s data can be performed in a mouse click, from the administrators’ section of the web interface (see 3.2).
• Update Botnet => SQL.
• Monitoring of the botnet. Data are gathered from each robot of the botnet and stored into a database table. These data will then be displayed and analyzed via the web interface (see 3.2).
• Information gathering with SOAP (Simple Object Access Protocol). The IRC network where the services where delivered (Undernet) proposed a SOAP interface, which we used to make sure our lent resources do not conflict with the official one proposed by the network.
• Update of the IRC network’s serverlist on the botnet. The IRC servers of Undernet are kindly hosted for free by companies or administrations, which can change their mind depending on their internal politics and/or if external network load or attacks impact on the overall performance of their network. As a result, the serverlist of Undernet was regularly subject to changes, and this automated procedure to update the serverlist on the botnet allowed sparing considerable administration time.

• This personal project was running from June 2001 to December 2003.

• Activity statistics :
• 700+ protected chat rooms.
• 2200+ requests.
• 2500+ registered users, from 47 countries.
• 80% load on average.
• 0 lost of operator status.

Our project fulfilled a need.

• Several marketing methods have been used, here under are the most efficient in our case :
• Word of mouth (the biggest catalyser because our users gave us, along with their request, the trust that our project would not mess with their chat room).
• Multiple partnership networks and cross-referencing.
• Publicly available demonstration account.

• This was a very interesting and constructive first experience for me in the directions of:
• IT project management, covering the fields of databases, development, networks and systems.
• Technical awareness (with it my first website).
• Long run team management experience. It was also in the context of a non-commercial association where none of the member was here for the money, but all as volunteers; this does not necessarily ease the managing tasks.

• I find it worth to note that in spite of deploying efforts to give our users the higher level of independence we could think of, there was still some who preferred to ask for support or advice to a human, even if the answer was easily findable in the FAQ. Finding the right balance between providing a help service without falling into the extreme of being at their service, while being friendly and polite, was part of the overall challenge. A way we used was to provide help to them, by giving guidance on how to perform operations in order to get their requested result (or telling them where to find appropriate help on this subject), instead of providing assistance by doing it on their behalf. A side effect was that helping users became more interesting: it was oriented to transmit knowledge more than just instructions.
• Providing help in this way has shown to take more time at the beginning, but we knew that in the long run, the helped user would be able to re-do the operation if needed to, and possibly help one of his mate facing a similar situation, on his chat room. We also experienced that some users joined our project’s chat room to give us a hand with this help task and/or to have some friendly chat with us, a small community started rising.

• Strengths
• Reputation and name: IRC is a world in constant and fast movement; this project remained reliable for a relatively long time, allowing it to enter the IRC community and opening doors to referencing:
• Through web links from other websites related to IRC.
• Through search engines and directories.
• By chat rooms on IRC.
• Modularity, automation and simplicity, allowing time to be spent on our users, not on technical tasks.
• Management of the whole chain (from server hosting to end-development), reducing the costs to the domain name registration at 12€/year.
• Weaknesses
• Requirements in initial resources relatively high (a minimum of 3 servers).
• In order to increase the overall reliability, the hub robot and the database should run from a HAC (High Availability Cluster).
• The web interface should not have been developed using frames.

• This has been the subject of my dissertation in September 2003 at Oxford Brookes University, for the Master’s in high speed networks and distributed systems.
• The source codes have been published under the BSD license, and are used by other associations.