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 network.
As a Windows NT administrator or chat sysop manager, you can control user activity and manage client connections on a chat network by:
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 do not affect sysops or sysop managers. For example, a defective bot operating as a sysop can accidentally flood a server.
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.
You set the Output saturation limit option from the User Classes Settings property sheet in the Chat Service Manager utility, or by using the chatcmd /AddClass or /SetClass options.
Note The server can also drop sysop manager and sysop connections. The saturation limit for sysop managers is 4 megabytes (MB). The limit for sysops is 1 MB.
Chat Service also uses an input flood limit to prevent a client from flooding a server’s inbound message queue. The input flood limit is the maximum amount of unprocessed data that a server can buffer from a client before the server drops the client connection.
You set the Input flood limit option from the User Classes Settings property sheet in the Chat Service Manager utility, or by using the chatcmd /AddClass or /SetClass options.
Although the input flood limit can effectively control some types of flooding, other flooding attacks require different measures. For example, an attacker can send users a continuous stream of short messages that are not large enough to reach the input flood limit, but large enough to annoy users.
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.
Delays the processing of all messages from a user class.
You set the Message processing delay option from the User Classes Settings property sheet in the Chat Service Manager utility, or by using the chatcmd /AddClass or /SetClass options.
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.
Attack protection 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 whispers). Also, if a user tries to join a channel using the wrong password, the server delays the processing of subsequent attempts by that user to join the channel. If the server receives one of these messages, it temporarily suspends a user’s session. After the delay expires, the server resumes normal processing.
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.
You set the Attack protection option from the User Classes Settings property sheet in the Chat Service Manager utility, or by using the chatcmd /AddClass or /SetClass options.
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 load in itself is not high enough to cause the connection to be dropped, this 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. Sysop managers and sysops are not affected by this limit.
You can set the Maximum IP connections option from the User Classes Settings property sheet in the Chat Service Manager utility, or by using the chatcmd /AddClass or /SetClass options.
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 attack.
If a user has a DNS host name, the server masks the first portion of the host name. For example, maria_black@ppp51.litware.com is published as maria_black@xxxxx.litware.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.
Sysop managers, sysops, channel owners, and channel hosts can see each user’s full IP address/DNS host name so they can, if necessary, remove or ban users from 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.
You enable IP/DNS masking from the User Classes Settings property sheet in the Chat Service Manager utility, or by using the chatcmd /AddClass or /SetClass options.
Note Authenticated user identifications (IDENTs) are displayed as 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.