Internet Relay Chat flood

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

A post flood on an IRC channel, repeating the term "OMG" several hundred times
Connect flood
Connecting and disconnecting from a channel as fast as possible, therefore spamming the channel with dis/connect messages also called q/j flooding.
CTCP flood
Since CTCP is implemented in almost every client, 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.
Invite flood
Sending disruptive amounts of invites to a certain channel.
Post flood
This is the simplest type of IRC flooding. It involves posting large amounts of posts or one very long post with repetitive text. This type of flood can be achieved, for example, by copying and pasting one short word repeatedly.


Example of a message flood using over 50 clones.
Message flood
Sending massive amounts 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.
Nick flood
Changing the nick as fast as possible, thus disrupting conversation in the channel.

Clones

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

Instead clones are used, which are script or program controlled clients, primarily 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. Usually, these proxies are SOCKS or Squid-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, some IRC servers[1] are configured to check common proxy ports of the clienst at the very beginning of the connection. If a successful proxy request can be done, it immediately drops the user (or clone). Many other IRC networks[2][3][4][5][6][7] use a separate proxy scanner like BOPM[8] that scans users as they join the network and kills or G-lines any users it detects an open proxy on. However, this offers no protection against compromised systems or proxies on non-standard ports (a full 65535 port scan isn't prototypically feasible both for performance reasons and because it risks setting off Intrusion Detection Systems), so most networks that do port scans also check if the connecting client is listed in specific DNSBLs like the TOR DNSBL.[9]

Flood 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.

Firewalls

Many users believe that installing a firewall will protect them against these attacks. However, most firewalls do not protect against application-layer denial-of-service attack.

Server-side

Certain IRC server packages, such as Charybdis and ircd-seven, provide a usermode (+g) which filters private messages on the server- side. A message recipient is notified of the first message, and can then choose to whitelist the sender on a session basis. This protects a client from attempts to flood it off the server.

See also

Notes

  1. ↑ ":: www.undernet.org - welcome to the undernet IRC network". undernet.org.
  2. ↑ http://proxyscan.freenode.net/
  3. ↑ http://irc.netsplit.de/networks/EsperNet/
  4. ↑ "OFTC - FAQ/IRC_Related_Questions". oftc.net.
  5. ↑ http://wiki.blitzed.org/Bans%2C_kills_and_K:_lines#K:_lined_by_Blitzed_OPM_.28BOPM.29
  6. ↑ "Rizon Abuse". rizon.net.
  7. ↑ chat.stratics.com/irc-proxyscan.html
  8. ↑ Do a "/whois BOPM" on OFTC or Blitzed, for example.
  9. ↑ "sectoor - Server, Domains, Housing und Hosting - security, leading to success". sectoor.de.

References

  • Pioch, Nicolas (1993-02-28). "A short IRC primer". Retrieved 2009-05-25. 
  • "Logging and Reporting IRC Abuses". Retrieved 2009-05-25. 
  • Brinton, Aaron (August 1997). "IRC Operators Guide". Retrieved 2009-05-25. 
  • Powers, Ray (1998-07-30). "The myths of opers....". Retrieved 2009-05-25. 
  • Reed, Darren (May 1992). "A Discussion on Computer Network Conferencing: 5.2.6 Network Friendliness". Rfc1324. IETF. Retrieved 2009-05-25. 
  • Oikarinen, Jarkko; Reed, Darren (May 1993). "Internet Relay Chat Protocol: 8.10 Flood control of clients". Rfc1459. IETF. Retrieved 2009-05-25. 
  • Kalt, Christophe (April 2000). "Internet Relay Chat: Server Protocol: 5.8 Flood control of clients". Rfc2813. IETF. Retrieved 2009-05-25. 
  • Mutton, Paul (2004-07-27). IRC Hacks (1st ed.). Sebastopol, CA: O'Reilly Media. pp. 302, 98, 134, 170 – 172, 268 – 269, 300. ISBN 0-596-00687-X. 
  • Grimes, Roger A. (August 2001). Malicious Mobile Code: Virus Protection for Windows. Sebastopol, CA: O'Reilly Media. pp. 188, 239 – 240, 242 – 243. ISBN 1-56592-682-X. 
  • (anonymous) (June 1997). Maximum Security: A Hacker's Guide to Protecting Your Internet Site and Network. SAMS Publishing. pp. 140 – 141. ISBN 1-57521-268-4. 
  • Crystal, David (2006-09-18). Language and the Internet (2nd ed.). Cambridge University Press. p. 160. ISBN 0-521-86859-9. 
  • Rheingold, Howard (October 1993). The Virtual Community: Homesteading on the Electronic Frontier (1st ed.). Basic Books. p. 185. ISBN 0-201-60870-7. 
  • Surratt, Carla G. (1999-08-01). Netaholics?: The Creation of a Pathology. Hauppauge, New York: Nova Science Publishers. p. 156. ISBN 1-56072-675-X. 
  • Gibbs, Donna; Krause, Kerri-Lee, eds. (2006-06-01). Cyberlines 2.0: Languages and Cultures of the Internet (2nd ed.). James Nicholas Publishers. pp. 270 – 271. ISBN 1-875408-42-8. 
  • Piccard, Paul; Baskin, Brian; Edwards, Craig; Spillman, George (2005-05-01). Sachs, Marcus, ed. Securing IM and P2P Applications for the Enterprise. foreword by Kevin Beaver (1st ed.). Rockland, Massachusetts: Syngress Publishing. ISBN 1-59749-017-2. 
  • McClure, Stuart; Scambray, Joel; Kurtz, George (2005-04-19). Hacking Exposed 5th Edition: Network Security Secrets And Solutions (5th ed.). New York, New York: McGraw-Hill Professional. pp. 494 – 497. ISBN 0-07-226081-5. 
  • Scambray, Joel; Shema, Mike; Sima, Caleb (2006-06-05). Hacking Exposed: Web Applications (2nd ed.). New York, New York: McGraw-Hill Professional. pp. 370 – 373. ISBN 0-07-226299-0. 
  • Tipton, Harold F.; Krause, Micki, eds. (2004-12-28). Information Security Management Handbook. 2 (5th ed.). Auerbach Publications. p. 517. ISBN 0-8493-3210-9. 
  • Harold F. Tipton, Micki Krause. (2007-05-14). Tipton, Harold F.; Krause, Micki, eds. Information Security Management Handbook (6th ed.). Auerbach Publications. ISBN 0-8493-7495-2. 
  • Maynor, David; James, Lance; Spammer-X; Bradley, Tony; Thornton, Frank; Haines, Brad; Baskin, Brian; Bhargava, Hersh; Faircloth, Jeremy; Edwards, Craig; Gregg, Michael; Bandes, Ron; Das, Anand M.; Piccard, Paul (November 2006). Emerging Threat Analysis: From Mischief to Malicious. Rockland, Massachusetts: Syngress Publishing. p. 170. ISBN 1-59749-056-3. 
  • Bidgoli, Hossein (2003-12-23). The Internet Encyclopedia (1st ed.). Hoboken, New Jersey: John Wiley & Sons. pp. 209, 213. ISBN 0-471-22201-1. 
  • Northcutt, Stephen; Novak, Judy (2002-09-06). Network Intrusion Detection (3rd ed.). SAMS Publishing. ISBN 0-7357-1265-4. 
  • Douligeris, Christos; Serpanos, Dimitrios N. (2007-06-15). Network Security: Current Status and Future Directions. Hoboken, New Jersey: John Wiley & Sons. ISBN 0-471-70355-9. 
  • Skoudis, Ed; Liston, Tom (2006-01-02). Counter Hack Reloaded: A Step-by-Step Guide to Computer Attacks and Effective Defenses (2nd ed.). Prentice Hall. ISBN 0-13-148104-5. 
  • King, Todd; Tittel, Ed; Bittlingmeier, David (2003-04-06). Security+ Training Guide. Que Publishing. ISBN 0-7897-2836-2. 
  • Baskin, Brian; Bradley, Tony; Faircloth, Jeremy; Schiller, Craig A.; Caruso, Ken; Piccard, Paul; James, Lance (2006-09-19). Piltzecker, Tony, ed. Combating Spyware in the Enterprise (1st ed.). Rockland, Massachusetts: Syngress Publishing. p. 19. ISBN 1-59749-064-4. 
  • Ho:o:k, Kristina; Benyon, David; Munro, Alan J., eds. (2003-01-31). Designing Information Spaces: The Social Navigation Approach (1st ed.). Germany: Springer Science+Business Media. p. 266. ISBN 1-85233-661-7. 
  • Schiller, Craig A.; Binkley, Jim; Harley, David; Evron, Gadi; Bradley, Tony; Willems, Carsten; Cross, Michael (2007-02-15). Botnets: The Killer Web App. Rockland, Massachusetts: Syngress Publishing. p. 80. ISBN 1-59749-135-7. 
This article is issued from Wikipedia - version of the 11/28/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.