Log in | Back to darenet.org

Flood Attacks

m
Line 202: Line 202:
Note from NudeDude: /ignore only works against CTCP in mIRC versions 4.0 and higher. It is a "client" level command and therefore still allows the CTCP info requests to reach you; it just stops the automatic CTCP reply by your client. Also, the global /ignore *!*@* in this particular example will shut off all channel text from reaching your for 25 seconds each time someone sends any CTCP to you.
Note from NudeDude: /ignore only works against CTCP in mIRC versions 4.0 and higher. It is a "client" level command and therefore still allows the CTCP info requests to reach you; it just stops the automatic CTCP reply by your client. Also, the global /ignore *!*@* in this particular example will shut off all channel text from reaching your for 25 seconds each time someone sends any CTCP to you.
-
[[Category:Documentation]]
+
[[Category:Documentation]] [[Category:IRC]]

Revision as of 22:51, 29 December 2009

What is a flood?

Good question. Flood attacks are fortunately a rare occurrence on DareNET. Flooding comes in several varieties, including:

Channel Text Floods

Multiple lines of text sent to the channel chat window, usually considered a flood if over about 5 lines.

Nick Floods

Changing nicks over and over rapidly causing the channel window to be flooded with nick change notices. Some recent versions of ircd (the software that links IRC servers together into a net) have limited the number of nick changes possible by a user within a short time so as to effectively end this form of flood.

Flash Floods

These are when a user on a shell (Unix) account sends a command code that causes the other shell (Unix) users on the channel to have their screen codes reset so that it becomes unreadable.

You can protect against it by typing "mesg n" (no quotation marks) at the shell prompt before running IRC. This will stop anyone from resetting your screen codes while you are on IRC.

DCC Floods

Attempts to send rapid and massive amounts of DCC chat requests and/or files to you. It is also possible to have your system overwhelmed by DCC text dump to you from a fast shell connection. The symptoms of that are to open a DCC chat and find your chat window filled with scrolling text characters and your system unable to respond to anything you do.

CTCP Floods

Where a user rapidly sends CTCP info requests to you. These are usually in the form of /ping, /version, /time, etc. Most client programs are setup to automatically respond to such requests by sending back the requested info. Therefore, your own system rapidly exceeds its sendq buffer allowance and causes you to disconnect. This is why the CTCP flood is the most troublesome for you. The other floods are annoying, but do not usually cause disconnects (with their associated loss of presence -- and therefore ops) on your channel.

ICMP Floods

These floods are initiated when a user sends a huge series of data packets that directly attacks your winsock (or other dialer). The ICMP sends a series of ping packets directly to your dialer (bypassing your client program) and keeps it busy so that it isn't able to reply to server ping activity requests. The result is that the server thinks you've left and your connection eventually times out and disconnects.

You will notice abundant activity in your modem lights if someone is ICMP-flooding you. If you use a winsock dialer that has IP tracing capability enabled, your winsock will display a log of the actual ICMP flood. A shareware program called netXray is available for use in Win95/XP that can do the same thing (and more). Other packet sniffers are also available. For more info on using firewalls, ask your service provider for information for configuring your clients to connect to a firewall on the ISP's server.

It's also important to note that these types of attacks do not actually pass through DareNET's server, thus, you should try and log any such attacks and contact the offender's ISP, not DareNET.

Local Port Flood

Early versions of mIRC have a bug that makes it possible for someone to flood your modem or printer port. I won't go into just how it's done, since it's too easy and I don't teach abuse, only how to prevent it. To correct the bug, add the following to your permanent ignore list by typing in at the command line:

/ignore -p com1*!*@*
/ignore -p com2*!*@*
/ignore -p com3*!*@*
/ignore -p com4*!*@*
/ignore -p prn!*@*
/ignore -p lpt!*@*

Format Floods

With the advent of mIRC 4.7, Color Floods and other Format floods are becoming more common (both accidentally and intentionally). OkeyDokey has developed an excellent discussion and FloodPro advice for these, and I include it here.

okeydokey's Format Flood Protection v1.2

Format flooding is upon us with the new color/bold/underline/ reverse text formatting enabled by mIRC 4.7. The following provides you with protection from both the eyesore of frenzied multi-coloring, and the malicious use of control codes for flooding purposes.

Below is the alias definition: put it in your aliases section. Attach to any flood protect lines in your Events chk^ alias command. Minimally, add /chk^ to your default level ON TEXT and ON ACTION flood protect lines.

chk^ if %ctrlchk = ON
 { if $strip($parms) != $null
 { %diff = $len($parms) - $len($strip($parms)) | if ( %diff > 0 )
 { echo $chan %diff control codes } | if ( %diff > %max^codes )
 { ignore -u20 $wildsite | raw mode $chan +b $wildsite
    | raw kick $chan $nick :excessive formatting
    | timer 1 300 raw mode $chan -b $wildsite
    | unset %diff } | if ((�0 isin $parms) |
    | (�16 isin $parms))
{ echo 4 $chan $nick said: $strip($parms) } } }

The alias, if the format flood protect switch is on:

  • checks to see if only a control code by itself has been sent to the channel. If so, it does not proceed.
  • checks to see if there are any control codes present. If so, it proceeds.
    • if the number of control codes exceed the maximum allowable limit you have set, it bans the site and kicks the user, removing the ban 5 minutes later.
    • if the message is concealed by the use of white text, the alias displays the 'hidden' message text to you.

Once you get a 'feel' for the number of codes carried by formatted messages, you can remove the echo advising you of the control code count:

if ( %diff > 0 ) { echo $chan %diff control codes } |

If you wish, put this in your popups for easy switching of the format flood protection:

Format Flood Protect...
.Status:echo -a Format flood protection is %ctrlchk - maximum
permitted control codes is %max^codes
.Enable:set -s %ctrlchk ON
.Disable:set -s %ctrlchk off
.Set Sensitivity:set -s %max^codes $$?="Maximum permitted control
codes:"
.Reset:set -s %ctrlchk ON | set -s %max^codes 20 | set -s %clrstrip
off | strip -c | echo -a Format flood protection is active, maximum
allowable control codes are 20.
.Color...
..Status:echo 2 Color stripping is %clrstrip
..Strip color:strip +c | set %clrstrip ON | echo -a Colors will NOT
be displayed - format flood protection does NOT include colors.
..Display color:strip -c | set %clrstrip off | echo -a Colors WILL
be displayed - format flood protection includes colors.

After installing, be sure to initialize the script by choosing "Reset."

Color controls count for 2 to 3 control codes, depending on the color. I suggest you start with a sensitivity of 20 (the default), run it for a while, and adjust it accordingly.

If you don't like watching colors, then /strip +c will prevent the display of incoming colors; I included a popup command to make it easy. You will still see your own, and will still be able to send color-formatted text. The Format flood protection will continue to protect you from other excess formatting, including alternating bold/unbold floods. These floods can slow screen display considerably, and can impair your cpu's ability to process other tasks, if you are on a slow system.

'Nukes

Another class of Denial of Service attacks (the formal terminology for any action by a user attempting to block or disconnect your system from the Internet) include, but are not limited to, the following:

ANUKE, CNUKE -- attacks that send a TCP/IP error protocol to your dialer telling it the connection has been broken and causing it to stop its connection; WINNUKE ("bluenuke" or "muerte") -- sends an invalid code to the Windows netbios on Port 139 (usually an OOB code) and causes Windows systems to freeze up and require rebooting (the dreaded blue screen showing "Fatal Error" is the most common symptom); and ICENUKE, which is actually a form of ICMP flood that uses highly fragmented packets whose individual parts are small enough to sneak past most thresholds of packet sniffers and even many firewalls. Symptoms are a slowdown or total freezeup of your system.

Flood Protection

Fortunately, every user has the tools already available to combat flooders in a responsible way. First of all, never retaliate against a flooder by flooding back. All flooding is wrong and abuses Undernet resources. Here is some advice to stop flooders:

Set up an alias key to /silence *!*@*. When a flooder starts, just hit that alias key. It will stop all CTCP from going to you. Then you can also /ignore *!*userid@host on the offender to silence any channel flooding to you or DCC and /msg. Get their userid@host from a /whois. You can /silence -*!*@* to turn off the global silence of CTCP later when the flooder has stopped. Set it up as another alias if you want.

Flood clones or other forms of attack that use up large amounts of server bandwidth should be reported to by joining #support. But beyond that, there is also a second effective step to take. Whenever a user floods you or otherwise is abusive beyond simple rudeness, you should contact their Service Provider (e-mail abuse@domain -- example: abuse@aol.com) and give the the userid@port.domain (from a /whois) of the offensive users together with the date and the exact time (together with timezone) that the abuse took place.

This information is sufficient for the Provider to cross-check against their own logs and identify the exact users that are the cause of the problem (even if they use a fake userid). Summarize the problem (and include a log of it if you can). Request that the provider remove the account of the abusive user. Most providers will be reluctant to do so at first, but be firm, polite, and persistant. Remind them that abuse of bandwidth is costly and may result in the entire provider's site being autokilled (banned) from all IRC servers. Also remind them that CTCP and ICMP flooding are "denials of service" and are expressly forbidden under Internet guidelines.

Good luck, and pass this info along to your friends AND enemies. :)

Script Examples

Below are some examples of mIRC scripting that I use in my Level 1 flood protection. You can follow the advice above withOUT setting up a script like the one shown below. The following scripts and aliases are a bit more advanced, and you can play with them if/when you feel up to it.

Remember -- you should never run a script you didn't write yourself, or at least run one in which you understand every line of code. The only exception should be the officially approved Support Department scripts.

The following lines are from the tools/remote/commands secton of CSCPAC (versions 4.7x, slight modifications need to be made for 5.x). They allow only one CTCP/site each 60 seconds.

[Commands]

1:*:{
  /auser =99 *!*@* $+ $site | /timer 1 60 /ruser *!*@* $+ $site
  if ($chan) { echo 10 -a [[ $+ $nick $parm1 $+ ] to $chan | halt }
}
99:*:{
  /raw silence *!*@* $+ $site | /ignore -pintu60 *!*@* $+ $site |
echo 10 -s $nick in $chan  | /timer 1 60 /ruser *!*@* $+ $site |
/timer 1 60 /raw silence -*!*@* $+ $site | echo 4 -a $nick at $site
on $chan has triggered floodpro for $parm1
  halt
}

Next, here are some alias key setups (from Tools/Aliases):

/f10 /ignore -tu15 *!*@* [sets F10 key to global ignore for 15 seconds]
/f11 /silence *!*@* [sets F11 key to global silence to stop all CTCP sends at the server]
/f12 /silence -*!*@* [turns off the global silence]

Some suggested #channel settings to help avoid flooders, especially clonefloods:

  • Always set your channel to mode +tn (e.g., /mode #channelname +tn).
  • Also consider keeping the channel set to mode +l with a limit about 4 higher then the usual channel occupancy. For example, if you usually have about 10 users there, then type /mode #channelname +l 14. Now, if a swarm of clones tries to get on your channel, as soon as the limit of 14 users in your channel is reached, then no more will be able to enter it.
  • Set your own personal mode to +i (/mode +i). This will make you NOT show up when someone outside your channel does a /who #channel or /names #channel or /who *domain. That will help keep people from outside you channel from finding you and harassing you.

For Nick Flood Protection, in your mIRC events window, add:

*1:on nick:#channel:/kick $newnick | /msg $knick no nick changes allowed in the channel

Here are some additional suggestions provided by other users:

From AngelBaby, an mIRC script for channel text flood protection:

Auto Kick ON Channel flood (by AngelBaby):

*1:on text:*:#silverlocke:/auser 2 $nick | /timer 1 6 /ruser $nick
*2:on text:*:#silverlocke:/auser 3 $nick
*3:on text:*:#silverlocke:/auser 4 $nick
*4:on text:*:#silverlocke:/kick $chan $nick Flood detected! Lose
the screen scroll!!! | /ruser $nick

From |VOID| -- a few other simple flood protect script and alias suggestions (similar to some of the features that are in CSCPAC):

Flood protection that is added to mIRC remote/commands window:

1:*:/ignore -tu25 *!*@* | /away One CTCP reply every 25 seconds
... Wait...The default user level at, say, 10. the default user
level MUST be the same as the number at the start of the line
| /timer 1 25 /away :>

(that all goes on a single line)

It ignores everyone after a CTCP, sends an /away msg to the server so that the server can reply to the user CTCP'ing when a limit is in place, so the server does the work, NOT the user. =) A timer is activated and the person who was CTCP'd turns the /away msg off after 25 seconds.

Therefore, the MOST that can happen in 25 seconds is:

  • response to CTCP request (this includes DCC, sound, etc.)
  • /away msg on
  • /away msg off

Also, a handy popup to have is:

FLooD PRoTeKTioN
.TuRN oN:/creq ignore | /sreq ignore | /silence +*!*@*
| /ignore *!*@*
.TuRN oFF:/creq auto | /sreq auto | /silence -*!*@* |
/ignore -r *!*@*

Note from NudeDude: /ignore only works against CTCP in mIRC versions 4.0 and higher. It is a "client" level command and therefore still allows the CTCP info requests to reach you; it just stops the automatic CTCP reply by your client. Also, the global /ignore *!*@* in this particular example will shut off all channel text from reaching your for 25 seconds each time someone sends any CTCP to you.