Wiki

http://en.wikipedia.org/wiki/Internet_Relay_Chat_flood This page was last modified on 24 March 2010 at 23:27.

Internet Relay Chat flood

From Wikipedia, the free encyclopedia

This article needs additional citations for verification.

Please help improve this article by adding reliable references. Unsourced material may bechallenged and removed. (May 2009)

Please help improve this article by expanding it. Further information might be found on the talk page. (May 2009)

Flooding or scrolling on an IRC network is a method of disconnecting users from an IRC server (a form of Denial of Service), exhausting bandwidth which causes network latency ('lag'), or just annoying users. Floods can either be done by scripts (written for a given client) or by external programs.

It is possible to flood a client off the network simply by sending them data faster than they can receive it and thus cause a quit with the "max sendq exceeded" message, but this is generally only feasible if the user's connection is already slow/lagging and/or the attacker has a very large number of connections to the IRC network. Therefore, more common flooding techniques are based on the fact that the maximum number of messages that can be sent in a specified interval is controlled on the IRC server. Once this value is exceeded messages are stored in a buffer and delayed. If the buffer is filled the client is disconnected with an "Excess Flood" quit message. By sending messages that request an automated reply some IRC clients can be forced to flood themselves off.

Types of floods

Crapflood

This is the simplest type of IRC flooding. It involves posting large amounts of posts or one very long post with repetitive text. It can also involve text with no meaning or no pertinence to the current discussion.[1] This type of flood is most commonly achieved by copying and pasting one short word repeatedly. Occasionally, when there are a large amount of small words, the entire message will be copied and pasted to produce massive amounts of text. This can, in turn, be done again, creating an exponential rise in the amount of text.

CTCP flood

Since CTCP is implemented in almost every client[citation needed], most users respond to CTCP requests. By sending too many requests, after a couple of answers they get disconnected from the IRC server. The most widely-used type is CTCP PING, although most clients also implement other CTCP replies.

DCC flood

Initiating many DCC requests simultaneously. Theoretically it can also be used to disconnect users, because the target client sends information back about what port is intended to be used during the DCC session.

ICMP flood

Typically referred to as a ping flood. This attack overloads the victim's internet connection with an amount of ICMP data exceeding the connection's capacity, potentially causing a disconnection from the IRC network. For the duration of the attack, the user's internet connection remains hindered. Technically speaking, this is not an IRC flood, as the attack itself doesn't traverse the IRC network at all, but operates entirely independent of anything but the raw internet connection and its IP protocol (of which ICMP is a subset). Even so, the actual IP address to flood (the address of the victim's connection) is frequently obtained by looking at the victim's user information (e.g. through the /whois or /dns command) on the IRC network.

Message flood

Sending lots of private messages to the victim, mainly from different connections called clones (see below). Since some clients separate the private conversations into another window, each new message could open a new window for every new user a message is received from. This is exploitable by sending messages from multiple names, causing the target client to open many new windows and potentially swamping the user with boxes. Sometimes the easiest way to close all the windows is to restart the IRC client, although scripts (client extensions) exist to 'validate' unknown nicknames before receiving messages from them.

Notice flood

Similar to the message, but uses the "notice" command.

Invite flood

Sending lot of invites.

Nick flood

Changing the nick as fast as possible, thus making the conversation unenjoyable in the channel.

Connect flood

Connecting and disconnecting from a channel as fast as possible, therefore spamming the channel with dis/connect messages, thus making the conversation unenjoyable.

Clones

Abusers do not flood from their own nicknames, because of the following reasons:

    • they can easily be K-Lined by administrators ('IRCops,' 'ServerOPs' or 'SOPs'),

    • banned from channels by operators ('ChanOPs' or 'OPs'),

    • from one user the flood is often not effective (The limits apply to the attacker too).

Instead clones are used, which are script or program controlled clients, primary designed to abuse others. When this method is used, it becomes easier to attack a user using many clones at the same time. Generally, the more clones an attacker has, the greater the chance of an attack succeeding. However the maximum connections from any one ip address are generally limited by the IRC network (either at the IRCD level or the services level).

One common way to increase the number of clones is by using open proxies. Basically these proxies are SOCKS orSquid-based, which support IRC connections by default. If one has a list of open proxies, he can use them to connect his clones through them to various IRC servers. Alternatively, compromised systems can be used to make the connections.

To prevent this, nowadays some IRC servers are configured to check common proxy ports of the client at the very beginning of the connection. If a successful proxy request can be done, it immediately drops the user (or clone). Other IRC networks use a separate proxy scanner that scans users as they join the network and kills or glines any users it detects an open proxy on. However this offers no protection against compromised systems or proxies on nonstandard ports (a full 65535 port scan isn't really feasible both for performance reasons and because it risks setting off Intrusion Detection Systems).

Protection

Almost every IRC client offers some kind of flood protection. These protections are based on the built-in "ignore" feature, which means that a given incoming message, CTCP, invitation, etc. will be blocked if the sender's hostmask matches any of the masks are defined in the ignore list. This is useful as few IRC networks implement the 'silence' command to reject messages by the server. In other words, every message will be posted to the correspondent user, whether it is a normal message or its content is intentionally malicious.

Many clients also limit the number of replies that can be sent in response to any incoming traffic from the network thus avoiding hitting the excess flood limit.

Flood protection in mIRC

There's also flood protection in the popular Windows-based client program, mIRC, in the Options menu. Users can set up some important values about how many incoming bytes are considered to be flooding, maximum incoming lines per user and ignorance time. Note that these settings are not enabled by default.

Despite these possibilities, there are much more sophisticated ways to eliminate flooding using mIRC scripts. These include additional features, such as CTCP cloaking, better message flood control, more adjustable flood triggers, and many others.

Firewalls and floods

Many users believe that installing a firewall will protect them against these attacks. But firewalls typically don't deal with this kind of application layer denial-of-service attack and no known application layer firewalls provide such protection for IRC at this time.

See also

Notes

    1. ^ An example of this would be someone posting the entire contents of a book or poem when the book or poem in question is unrelated to discussion.

References

Example of a message flood using over 50 clones.

A post flood on #wikipedia-en, using the common Internet term "OMG".

This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improvethis article by introducing more precise citations where appropriate. (May 2009)