Chat Service includes security enhancements that can help you reduce, and in many cases prevent, attacks that can disrupt service or compromise the security of your chat community.
As an administrator, you can:
Flooding attacks occur when an attacker loads a chat server or client beyond its capacity by sending a large amount of information to be processed. For example, an attacking user can cause another user's screen to scroll too fast to follow a chat session. This can also cause a user to be disconnected from the service.
Important
The safeguards described in this section are not imposed upon
Chat Service uses an output saturation limit to control volume flooding on the server. The output saturation limit is the maximum amount of data that the server can buffer for a client before the server drops the client connection. Set the Output saturation limit option on the user classes Settings tab.
Note The server can also drop sysop connections. The saturation limit for sysops is 1 MB.
Other types of flooding attacks require different measures. For example, an attacker can send users a continuous stream of short nonsense messages that are not large enough to reach the input flood limit, but are large enough to make the recipients' screens scroll so quickly that the screen is unreadable.
You can control this type of flooding by applying a delay to user connections. A delay is the period of time, measured in seconds, that the server waits before processing the next message from a client.
Set the Message processing delay option on the user classes Settings tab.
Channel lag adds an additional delay to any message sent to a channel. The server adds the channel lag to any other delay that is in effect. To set the channel lag, use the IRCX PROP command. You can set a value from 0 to 2 seconds. The default setting is 0 (no lag).
Note Actual lag times can vary plus-or-minus 1 second.
The Attack protection level enables you to regulate the
flow of traffic from a class of users by limiting the frequency
with which the server processes data messages, invitations, join
messages, messages from the host to the channel, and standard
messages (such as notices and
There are four levels of attack protection. Each level corresponds to a specific delay time according to the type of message. This delay time is added to the message processing delay and channel lag settings. On the user classes Settings tab, set the Attack protection level option.
A clone attack occurs when an attacker establishes several connections to a server from a single IP address and applies a load to each connection. Although each individual load is not large enough to cause the connection to be dropped, the combined effect can prevent the server from accepting new connections from other users.
You can prevent clone attacks by limiting the number of connections per IP address within a user class. Sysops and chat administrators are not affected by this limit. Set the Maximum IP connections option on the user classes Settings tab.
Direct client attacks occur when a chat client launches an attack on another client. A user who knows the IP address of another client can send large amounts of data directly through the Internet to flood that client's modem connection. You can reduce the likelihood of direct client attacks by enabling IP/DNS masking, which masks a portion of each user's IP address or DNS host name. The partial address or host name enables users to know the general location of other chat clients without exposing those clients to possible attack.
If a user has a DNS host name, the server masks the first portion of the host name. For example, suzanfines@nwtraders.microsoft.com is published as suzanfines@xxxxx.microsoft.com. If a user has no DNS host name, the server masks the last number of the IP address. For example, the address 10.55.17.122 is published as 10.55.17.xxx.
Sysops, channel owners, and channel hosts (or chat administrators who have assumed one of these roles and are logged on to a chat client) can see each user's full IP address/DNS host name so they can, if necessary, remove or ban users from the Chat Service or a specific channel. Channel owners and hosts can only see the full IP address/DNS host name of users in their channels.
Enable the masking of IP addresses and DNS names from the user classes Access tab.
Note Authenticated user identifications (IDENTs) are displayed using the format "USERID@domain." This form of identification reveals nothing about the client's location and effectively prevents any user from obtaining IP information from the authenticated user's account.
Related Topics
Protect a Chat Community from Attack