Jump to content

IRC flood: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
No edit summary
 
(174 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Cleanup rewrite|date=January 2012}}
'''Flooding''' or '''scrolling''' on an [[Internet Relay Chat|IRC]] network is a method of disconnecting users from the IRC server (like [[Denial of Service]]), or just making them slow ('[[lag]]gy'). Floods can either be done by scripts (written for the given client) or by external programs.
'''Internet Relay Chat Flooding/Scrolling''' on an [[Internet Relay Chat|IRC]] network is a method of disconnecting users from an IRC server (a form of [[Denial of Service]]), exhausting bandwidth which causes network latency ('[[Latency (engineering)|lag]]'), or just disrupting users. Floods can either be done by scripts (written for a given client) or by external programs.


==History==
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 users connection is already slow/lagging and/or the attacker has a very large number of connections to the IRC network.
The history of Internet Relay Chat flooding started as a method of [[Internet Relay Chat takeover|taking over]] an IRC channel from the original founders of the channel.

The first attacks generally used a modified IRC client or an application to flood a channel or a user.
Therefore, more commonly 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.
Later they started to be based on [[IRC bot|bots]] and [[Internet Relay Chat script|scripts]].
This later moved on to starting IRC-based botnets which were capable of DDoS and IRC floods.


==Types of floods==
==Types of floods==
[[Image:IRC flooding.PNG|right|thumb|A post flood on #wikipedia-en, using the common Internet term "[[OMG]]".]]
[[File:IRC flooding.PNG|thumb|A post flood on an IRC channel, repeating the term "[[SMS language#SMS dictionaries|OMG]]" several hundred times]]
; 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. It can also involve text with no meaning or no pertinence to to the current discussion.<ref>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.</ref> This type of flood is most commonly achieved by copying and pasting one short word repeately. Occasionally, when there is 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.


===Connect flood===
; [[Client-To-Client Protocol|CTCP]] flood : These are probably the most common and most efficient. Since CTCP is implemented in almost every client, every user responds 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.
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===
; [[Direct Client-to-Client|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.
Since [[Client-To-Client Protocol|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 some clients also implement other CTCP replies.


===DCC flood===
; [[Internet Control Message Protocol|ICMP]] flood : Typically referred to as a [[ping]] flood. This attack overloads the victim's bare internet connection with an amount of data exceeding the connection's capacity, causing not only a disconnection from the IRC network (seen by observers as a quit due to "Ping timeout"), but a failure of the victim's internet connection itself, either slowing it down severely or effectively disabling it's functionality completely for the duration of the attack. 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 it's 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 (ie. through the /whois command) on the IRC network, and it's a popular IRC-based means of [[Denial-of-service attack|DoS]] attack.
This type consists of initiating many [[Direct Client-to-Client|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===
[[Image:Private message flood 2006 freenode.PNG|right|300px|thumbnail|Example of a message flood using over 50 clones.]]
Typically referred to as a [[Ping (networking utility)|ping]] flood. This attack overloads the victim's internet connection with an amount of [[Internet Control Message Protocol|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 many clients separate the private conversations into another window, they 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.


===Invite flood===
; Notice flood : Similar to the message, but uses the "notice" command.
Sending disruptive numbers of invites to a certain channel.


===Post flood===
; Invite flood : Sending lot of invites, mostly to fake channels.
This is the simplest type of IRC flooding. It involves posting large numbers 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.


[[File:Private message flood 2006 freenode.PNG|thumbnail|Example of a message flood using over 50 clones.]]
; Nick flood : the coolest kind of flood. they usually don't like being interupted by IP protocol. If a victim of a Nick Flood gets killed, then use the big head of the Se-Ah-Moose and attempt to save the victim. If you are lucky, the Nick Flood won't kill you either.


===Message flood===
; Join/part flood : Joining and parting from a specified channel. The effect is the same as that of the nick flood. Again, this will often result in a ban.
Sending massive numbers 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.


==Clones==
===Notice flood===
Similar to the message, but uses the "notice" command.
Of course, abusers do not flood from their own nicknames, because of the following reasons:
* they can easily be [[K-line|K-Lined]] by administrators ('[[IRC operator|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).


===Nick flood===
Instead clones are used, which are script or program controlled clients, primary designed to
Changing the nick as fast as possible, thus disrupting conversation in the channel.
abuse others. Thanks to this, it's pretty easy to attack a user by many clones at the
same time. Generally, the more clones an abuser has, the bigger the chance is 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 using open [[proxy server|proxies]]. Basically these proxies are [[SOCKS]] or [[Squid cache|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, 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 [[gline]]s 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 network abuse detectors).

==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 [[Microsoft Windows|Windows]]-based client program, [[mIRC]], in the Options menu. Users can setup 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 is a much more sophisticated way to eliminate flooding by using [[mIRC script]]s. These include additional features, such as CTCP cloaking, better message flood control, more adjustable flood triggers, and many others.

===[[Firewall (networking)|Firewalls]] and floods===
Many users believe that installing a firewall will protect them against these attacks. This is not true, because the [[Internet Relay Chat|IRC]] [[Communications protocol|protocol]] operates in the [[application layer]], therefore a packet filter firewall cannot examine the incoming data stream to filter the flood. Neither does an application layer firewall provide such protection - it would be too complex to implement such a feature.


==See also==
==See also==
* [[Computer security]]
* [[Computer security]]
* [[WinNuke]]
* [[Flood]]
* [[Smurf attack]]
* [[Smurf attack]]
* [[WinNuke]]


== Notes ==
== References ==
{{More footnotes|date=May 2009}}
<references/>
{{Reflist}}
{{Refbegin|2}}
* {{cite web
|url = http://irc.carnet.hr/docs/docs/primer.txt
|title = A short IRC primer
|access-date = 2009-05-25
|last = Pioch
|first = Nicolas
|date = 1993-02-28
|archive-url = https://web.archive.org/web/20090814234709/http://irc.carnet.hr/docs/docs/primer.txt
|archive-date = 2009-08-14
}}
* {{cite web
|url = http://irc.carnet.hr/docs/docs/abuse.txt
|title = Logging and Reporting IRC Abuses
|access-date = 2009-05-25
|archive-url = https://web.archive.org/web/20090815124832/http://irc.carnet.hr/docs/docs/abuse.txt
|archive-date = 2009-08-15
}}
* {{cite web
|url = http://irc.carnet.hr/docs/docs/opersguide.txt
|title = IRC Operators Guide
|access-date = 2009-05-25
|last = Brinton
|first = Aaron
|date = August 1997
|archive-url = https://web.archive.org/web/20090814234703/http://irc.carnet.hr/docs/docs/opersguide.txt
|archive-date = 2009-08-14
}}
* {{cite web
|url = http://irc.carnet.hr/docs/docs/opermyth.txt
|title = The myths of opers....
|access-date = 2009-05-25
|last = Powers
|first = Ray
|date = 1998-07-30
|archive-url = https://web.archive.org/web/20090815124846/http://irc.carnet.hr/docs/docs/opermyth.txt
|archive-date = 2009-08-15
}}
* {{cite ietf
| last = Reed
| first = Darren
|date=May 1992
| title = A Discussion on Computer Network Conferencing: 5.2.6 Network Friendliness
| rfc = 1324
| publisher = [[Internet Engineering Task Force|IETF]]
| url = http://tools.ietf.org/html/rfc1324#section-5.2.6
| access-date = 2009-05-25
}}
* {{cite ietf
| last = Oikarinen
| first = Jarkko
| author-link = Jarkko Oikarinen
|author2=Reed, Darren
|date=May 1993
| title = Internet Relay Chat Protocol: 8.10 Flood control of clients
| rfc = 1459
| publisher = [[Internet Engineering Task Force|IETF]]
| url = http://tools.ietf.org/html/rfc1459#section-8.10
| access-date = 2009-05-25
}}
* {{cite ietf
| last = Kalt
| first = Christophe
|date=April 2000
| title = Internet Relay Chat: Server Protocol: 5.8 Flood control of clients
| rfc = 2813
| publisher = [[Internet Engineering Task Force|IETF]]
| url = http://tools.ietf.org/html/rfc2813#section-5.8
| access-date = 2009-05-25
}}
* {{cite book
| last = Mutton
| first = Paul
| title = IRC Hacks
| edition = 1st
| date = 2004-07-27
| publisher = [[O'Reilly Media]]
| location = [[Sebastopol, CA]]
| isbn = 0-596-00687-X
| pages = 302, 98, 134, 170–172, 268–269, 300
}}
* {{cite book |last = Grimes
|first = Roger A.
|title = Malicious Mobile Code: Virus Protection for Windows
|date = August 2001
|publisher = [[O'Reilly Media]]
|location = [[Sebastopol, CA]]
|isbn = 1-56592-682-X
|pages = [https://archive.org/details/maliciousmobilec00grim/page/188 188, 239–240, 242–243]
|url = https://archive.org/details/maliciousmobilec00grim/page/188
}}
* {{cite book
| last = (anonymous)
| title = Maximum Security: A Hacker's Guide to Protecting Your Internet Site and Network
| date = June 1997
| publisher = [[SAMS Publishing]]
| isbn = 1-57521-268-4
| pages = [https://archive.org/details/maximumsecurityh00anon/page/140 140–141]
| url = https://archive.org/details/maximumsecurityh00anon/page/140
}}
* {{cite book
| last = Crystal
| first = David
| title = Language and the Internet
| url = https://archive.org/details/languageinternet00crys_700
| url-access = registration
| edition = 2nd
| date = 2006-09-18
| publisher = [[Cambridge University Press]]
| isbn = 0-521-86859-9
| page = [https://archive.org/details/languageinternet00crys_700/page/n173 160]
}}
* {{cite book |last = Rheingold
|first = Howard
|title = The Virtual Community: Homesteading on the Electronic Frontier
|edition = 1st
|date = October 1993
|publisher = [[Basic Books]]
|isbn = 0-201-60870-7
|page = [https://archive.org/details/virtualcommunity00rhei/page/185 185]
|url = https://archive.org/details/virtualcommunity00rhei/page/185
}}
* {{cite book
| last = Surratt
| first = Carla G.
| title = Netaholics?: The Creation of a Pathology
| date = 1999-08-01
| publisher = [[Nova Science Publishers]]
| location = [[Hauppauge, New York]]
| isbn = 1-56072-675-X
| page = 156
}}
* {{cite book
| editor1-last = Gibbs
| editor1-first = Donna
| editor2-last = Krause
| editor2-first = Kerri-Lee
| title = Cyberlines 2.0: Languages and Cultures of the Internet
| edition = 2nd
| date = 2006-06-01
| publisher = [[James Nicholas Publishers]]
| isbn = 1-875408-42-8
| pages = 270–271
}}
* {{cite book
| last1 = Piccard
| first1 = Paul
| last2 = Baskin
| first2 = Brian
| last3 = Edwards
| first3 = Craig
| last4 = Spillman
| first4 = George
| editor1-last = Sachs
| editor1-first = Marcus
| editor1-link = Marcus Sachs
| others = foreword by Kevin Beaver
| title = Securing IM and P2P Applications for the Enterprise
| edition = 1st
| date = 2005-05-01
| publisher = [[Syngress Publishing]]
| location = [[Rockland, Massachusetts]]
| isbn = 1-59749-017-2
}}
* {{cite book
| last1 = McClure
| first1 = Stuart
| last2 = Scambray
| first2 = Joel
| last3 = Kurtz
| first3 = George
| title = Hacking Exposed 5th Edition: Network Security Secrets And Solutions
| edition = 5th
| date = 2005-04-19
| publisher = [[McGraw-Hill Professional]]
| location = [[New York, New York]]
| isbn = 0-07-226081-5
| pages = 494–497
}}
* {{cite book
| last1 = Scambray
| first1 = Joel
| last2 = Shema
| first2 = Mike
| last3 = Sima
| first3 = Caleb
| title = Hacking Exposed: Web Applications
| edition = 2nd
| date = 2006-06-05
| publisher = [[McGraw-Hill Professional]]
| location = [[New York, New York]]
| isbn = 0-07-226299-0
| pages = 370–373
}}
* {{cite book
| editor1-last = Tipton
| editor1-first = Harold F.
| editor2-last = Krause
| editor2-first = Micki
| title = Information Security Management Handbook
| edition = 5th
| volume = 2
| date = 2004-12-28
| publisher = [[Auerbach Publications]]
| isbn = 0-8493-3210-9
| page = 517
}}
* {{cite book
| editor1-last = Tipton
| editor1-first = Harold F.
| editor2-last = Krause
| editor2-first = Micki
| title = Information Security Management Handbook
| edition = 6th
| date = 2007-05-14
| publisher = Auerbach Publications
| isbn = 978-0-8493-7495-1
| author = Harold F. Tipton, Micki Krause.
}}
* {{cite book
| last = Maynor
| first = David
|author2=James, Lance |author3=Spammer-X |author4=Bradley, Tony |author5=Thornton, Frank |author6=Haines, Brad |author7=Baskin, Brian |author8=Bhargava, Hersh |author9=Faircloth, Jeremy |author10=Edwards, Craig |author11=Gregg, Michael |author12=Bandes, Ron |author13=Das, Anand M. |author14=Piccard, Paul
| title = Emerging Threat Analysis: From Mischief to Malicious
| url = https://archive.org/details/syngressforceeme00greg_378
| url-access = registration
|date=November 2006
| publisher = Syngress Publishing
| location = [[Rockland, Massachusetts]]
| isbn = 1-59749-056-3
| page = [https://archive.org/details/syngressforceeme00greg_378/page/n200 170]
}}
* {{cite book
| last = Bidgoli
| first = Hossein
| title = The Internet Encyclopedia
| url = https://archive.org/details/internetencyclop00bidg
| url-access = registration
| edition = 1st
| date = 2003-12-23
| publisher = [[John Wiley & Sons]]
| location = [[Hoboken, New Jersey]]
| isbn = 0-471-22201-1
| pages = [https://archive.org/details/internetencyclop00bidg/page/n239 209], 213
}}
* {{cite book
| last1 = Northcutt
| first1 = Stephen
| last2 = Novak
| first2 = Judy
| title = Network Intrusion Detection
| edition = 3rd
| date = 2002-09-06
| publisher = [[SAMS Publishing]]
| isbn = 0-7357-1265-4
}}
* {{cite book |last1 = Douligeris
|first1 = Christos
|last2 = Serpanos
|first2 = Dimitrios N.
|title = Network Security: Current Status and Future Directions
|date = 2007-06-15
|publisher = [[John Wiley & Sons]]
|location = [[Hoboken, New Jersey]]
|isbn = 978-0-471-70355-6
|url = https://archive.org/details/networksecurityc00doul
}}
* {{cite book
| last1 = Skoudis
| first1 = Ed
| last2 = Liston
| first2 = Tom
| title = Counter Hack Reloaded: A Step-by-Step Guide to Computer Attacks and Effective Defenses
| edition = 2nd
| date = 2006-01-02
| publisher = [[Prentice Hall]]
| isbn = 0-13-148104-5
}}
* {{cite book
| last1 = King
| first1 = Todd
| last2 = Tittel
| first2 = Ed
| last3 = Bittlingmeier
| first3 = David
| title = Security+ Training Guide
| date = 2003-04-06
| publisher = [[Que Publishing]]
| isbn = 0-7897-2836-2
}}
* {{cite book
| last1 = Baskin
| first1 = Brian
| last2 = Bradley
| first2 = Tony
| last3 = Faircloth
| first3 = Jeremy
| last4 = Schiller
| first4 = Craig A.
| last5 = Caruso
| first5 = Ken
| last6 = Piccard
| first6 = Paul
| last7 = James
| first7 = Lance
| editor1-last = Piltzecker
| editor1-first = Tony
| title = Combating Spyware in the Enterprise
| edition = 1st
| date = 2006-09-19
| publisher = Syngress Publishing
| location = [[Rockland, Massachusetts]]
| isbn = 1-59749-064-4
| page = 19
}}
* {{cite book
| editor1-last = Höök
| editor1-first = Kristina
| editor2-last = Benyon
| editor2-first = David
| editor3-last = Munro
| editor3-first = Alan J.
| title = Designing Information Spaces: The Social Navigation Approach
| edition = 1st
| date = 2003-01-31
| publisher = [[Springer Science+Business Media]]
| location = [[Germany]]
| isbn = 1-85233-661-7
| page = 266
}}
* {{cite book
| last1 = Schiller
| first1 = Craig A.
| last2 = Binkley
| first2 = Jim
| last3 = Harley
| first3 = David
| last4 = Evron
| first4 = Gadi
| last5 = Bradley
| first5 = Tony
| last6 = Willems
| first6 = Carsten
| last7 = Cross
| first7 = Michael
| title = Botnets: The Killer Web App
| url = https://archive.org/details/botnetskillerweb00schi
| url-access = registration
| date = 2007-02-15
| publisher = Syngress Publishing
| location = [[Rockland, Massachusetts]]
| isbn = 978-1-59749-135-8
| page = [https://archive.org/details/botnetskillerweb00schi/page/n97 80]
}}
{{Refend}}


==External links==
==External links==
* [http://www.mircscripts.com mIRC script database]
* [http://www.mircscripts.com mIRC script database]
* [http://www.irchelp.org/irchelp/mirc/flood.html Flood protection and ignoring information]
* [https://web.archive.org/web/20050120085737/http://www.irchelp.org/irchelp/mirc/flood.html Flood protection and ignoring information]


{{IRC topics}}
[[Category:IRC]]


[[de:Flood (IRC)]]
[[Category:IRC|Flood]]
[[es:Flood]]
[[fr:Flood (IRC)]]
[[it:Flood]]
[[no:Flooding]]
[[pl:Flood (informatyka)]]
[[ru:Флуд]]
[[fi:Floodaus]]

Latest revision as of 05:49, 6 June 2024

Internet Relay Chat Flooding/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 disrupting users. Floods can either be done by scripts (written for a given client) or by external programs.

History[edit]

The history of Internet Relay Chat flooding started as a method of taking over an IRC channel from the original founders of the channel. The first attacks generally used a modified IRC client or an application to flood a channel or a user. Later they started to be based on bots and scripts. This later moved on to starting IRC-based botnets which were capable of DDoS and IRC floods.

Types of floods[edit]

A post flood on an IRC channel, repeating the term "OMG" several hundred times

Connect flood[edit]

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[edit]

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 some clients also implement other CTCP replies.

DCC flood[edit]

This type consists of 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[edit]

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[edit]

Sending disruptive numbers of invites to a certain channel.

Post flood[edit]

This is the simplest type of IRC flooding. It involves posting large numbers 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[edit]

Sending massive numbers 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[edit]

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

Nick flood[edit]

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

See also[edit]

References[edit]

External links[edit]

Retrieved from "https://en.wikipedia.org/w/index.php?title=IRC_flood&oldid=1227514171"