Microsoft Exchange 2000 Server Adminstrator's Companion
Microsoft Exchange Chat Service provides an environment for online group discussions. One Chat server can handle anywhere from a few users up to 20,000 concurrent users in one chat room. Each administrative group in the Exchange System snap-in can have only one Chat Communities container in which multiple virtual chat communities can be created. Each chat community can host multiple chat rooms, or channels, and can be governed by its own administrative controls.
The Chat Service of Exchange 2000 Server is based on the Internet Relay Chat (IRC) protocol, which supports real-time conversations between two or more users. With IRC, people meet on channels to talk in groups or privately about specific topics. Extended IRC (IRCX) is a set of extensions developed by Microsoft that enhances the functionality of the IRC protocol and adds new commands that you can use to manage users and channels on a Chat server.
Chat Service operates independently of other servers running Chat Service, using separate user and channel lists. Users contact Chat Service over TCP port 6667, which is usually the port number assigned to the first chat community. Port 7000 is also available, although other port numbers can be used if necessary. Any IRC-based client that is RFC 1459 compliant, such as mIRC ( http://www.mirc.com) or PIRCH ( http://www.pirch.com), will work.
Channels
A channel is a virtual place where people meet to engage in conversations. When a user joins a channel, the user can read anything that is typed to members of the channel. Channels are also called chat rooms.
There are two types of channels: registered and dynamic. Registered channels are created by the system administrator and are permanent. They can be divided into two categories: those that start when someone joins the channel and those that start automatically when Chat Service starts. Any started channels that are not secret or hidden are visible and can be displayed in a chat client with the List or Listx command.
Dynamic channels are temporary channels that a user creates from the client by using the IRC Join command or the IRCX Create command. A channel host manages a channel from the chat client. Only dynamic channels have channel hosts. The first person to join a channel automatically becomes the channel host. This status can be shared with other chat users. The user who is the channel host is referred to as a channel operator or chanop.
You should be aware of one other role in a chat community, and that is the sysop. A sysop is a user who monitors and controls a chat community's dynamic channels—as well as any registered channels to which the sysop has been given permissions—from a chat client. The sysop can also close a channel by using the IRC Kill command without having owner privileges on that channel. Sysops have no special permissions in a channel unless Chat Sysop Joins As Owner is selected on the channel's Modes tab.
To prevent someone from impersonating a sysop, only a sysop's nickname can begin with the following strings: "sysop," "orwell," "ChanServ," "CodeServ," "HelpServ," "MemoServ," and "NickServ." For example, any user can use the nickname "marysysop," but only a sysop can use the nickname "sysopmary." The terms "system" and "service" cannot begin or be contained in any nickname, including that used by a sysop.
You can configure channels to be either secure or cloneable or both. A secure channel is one to which access is restricted. You can restrict a channel to allow only authenticated users, invited users, or users who enter the correct password. In addition, you can restrict channels with Active Directory security settings by identifying only a group of user accounts or a selected number of group accounts as channel users. Finally, channels can be moderated, meaning that only those who have been granted a "voice" can speak.
A cloneable channel is a registered channel that automatically duplicates itself when its member limit is reached. Any security settings that are configured for the initial channel will be duplicated in the new channel.
Controlling User Connections to a Chat Community
You can control who can connect to a chat community and who cannot in two basic ways. User classes let you control connection by a group of users without the need to create a formal group in Active Directory. User bans enable you to control access on a per-user basis. Let's discuss each of these briefly.
User Classes
You can group users into classes and then assign Chat Service permissions and restrictions to those classes. In addition, you can control users' ability to create or join dynamic channels, restrict a class of users from logging on to a chat community, or become a channel owner or host. Class membership is based on one or more of the following criteria:
- Whether the user is logged on as an authenticated user or as an anonymous user
- The nickname, user name, domain name, or IP address of the user
- The time of day
When a user logs on to Chat Service, the service searches the existing classes in alphanumeric order by class name. If the user matches any of the selection criteria for a defined class, Chat Service adds the user to the first matching class and applies that class's restrictions to the user. If a user meets the criteria for more than one class, the user is added only to the first class that produces a match.
To create a user class, start the Exchange System snap-in, right-click the Classes folder under the chat community, point to New, and then choose Class. Figure 18-1 shows the General tab of the property sheet for a new user class. Enter the class name, and then configure the member scope by either completing the three fields for the identity mask or by specifying the IP address and subnet mask.
Figure 18-1. General tab of the property sheet for a new user class.
In the Identity Mask options, both the asterisk (*) and the question mark (?) are considered wildcard characters. It is important to understand that Chat Service considers all three fields when applying a user class. Table 18-2 give some examples.
Table 18-2. Examples of identity masks
| Nickname | User Name | Domain or IP address | Result |
|---|---|---|---|
| Crude | * | * | The user class comprises all users with the nickname of Crude from anywhere. |
| ? | * | *.net | The user class comprises all users originating from a .net domain. |
| * | * | * | The user class applies to all users connecting to Chat Service. |
| * | US* | * | The user class comprises users whose user name begin with US. |
| * | * | hr.oaktree.com | The user class comprises users coming from the hr.oaktree.com domain. |
Figure 18-2 shows the Access tab for the user class property sheet. Here you can further define the class based on the users' logon state and then, in the Restrictions area, stipulate what users who belong to this class cannot do. You can also enable the user class for certain times of the day—perhaps when the users are most likely to be using Chat Service.
The Hide Class Members' IP Addresses And DNS Names check box is a way to prevent one chat user from launching an attack on another chat user. A user who knows the IP address of another client can send large amounts of data directly to that client's connection, flooding it. You can reduce the likelihood of direct client attacks by masking a portion of each user's IP address or DNS host name.
Figure 18-2. Access tab of the property sheet for a new user class.
The Settings tab (Figure 18-3) sets protection levels to prevent attacks from bringing down your server. There are four choices for the attack protection level: None, Low, Medium, and High. If Chat Service receives one of these messages, it temporarily suspends the user's session. After the delay expires, the service resumes normal message processing. As shown in Table 18-3, each attack protection level corresponds to a delay time in seconds, based on the type of message or event. The attack protection delay is added to the message processing delay, which you set on this tab, and the channel lag delay, which you set with the Prop command (discussed in the Real World sidebar "Preventing Chat Service Attacks").
In the Limits area, you can enter the following values:
- Maximum IP Connections Regulates the number of connections per IP address for this user class. (This limit does not affect sysops and chat administrators.)
- Maximum Channels User Can Join Regulates the number of concurrent channels that a user can be chatting on. The server tracks this number based on a user's nickname. All channel messages are funneled through the same port number on both server and client.
- Output Saturation Limit (KB) Indicates the maximum amount of data that the server will buffer for a client before dropping the client connection.
Table 18-3. Attack protection levels
| Message Type or Event | None | Low | Medium | High |
|---|---|---|---|---|
| Data | 0 | 1 | 2 | 3 |
| Invitation | 0 | 2 | 4 | 5 |
| Join | 0 | 2 | 3 | 4 |
| Wrong channel password | 0 | 2 | 4 | 5 |
| Standard message, such as a Privmsg, Notice, or Whisper command | 0 | 1 | 2 | 3 |
| Message from host to channel | 0 | 1 | 1 | 2 |
Figure 18-3. Settings tab of the property sheet for a new user class.
In the Delays area, you can configure the Ping Delay (Seconds) parameter. The PING message is used to test whether an active client is present at the other end of a connection. In a sense, it is a heartbeat that is sent from the server to the client after the configured number of seconds of inactivity. Any client that receives a PING message must respond as quickly as possible with a PONG message. This indicates to the server that the client is still there and is alive. If the client fails to respond, the server severs the connection to the client. You can set this timeout value to any value between 15 and 3599 seconds. Both the PING and the PONG message packets are only 83 bytes, so unless you manage a large number of users using Chat Service, this activity should have a minimal effect on your bandwidth.
In the Delays area, you can also configure the Message Processing Delay (Seconds) option, which regulates the amount of time the server waits before processing the next message from all clients. The default is 0, but you can set it for up to 10 seconds. Finally, the Nickname Change Delay (Seconds) option regulates how often (in seconds) a user can change his or her nickname.
Real World Preventing Chat Service Attacks
Microsoft's Chat Service includes security features that can help you reduce and, in many cases, prevent attacks on your Chat servers. You need to defend yourself against three types of attacks: flooding attacks, clone attacks, and direct client attacks.
Flooding Attacks Flooding attacks occur when an attacker floods a Chat server by sending a large amount of information to be processed, exceeding the capacity of the Chat server. An attacking user can also cause another user's screen to scroll too fast, making it impossible to follow a chat session.
You can specify an output saturation limit on a per-class basis to control flooding on the server. This limit specifies the maximum amount of data that the server can buffer for a client before the server drops the client connection.
The server can also drop sysop connections. The saturation limit for sysops is hard-coded at 1 MB.
Other types of flooding attacks require different measures. For example, an attacker can send users a continuous stream of short messages that are too small to reach the Auto Ignore Flooders 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. This value is set in the Message Processing Delay box on the Settings tab.
Channel lag adds an additional delay to any message sent to a channel. This lag is added to any other delay that is in effect. To set the channel lag, use the IRCX Prop command. You can set a value of from 0 to 2 seconds. The default setting is 0 (no lag). Actual lag times can vary by plus or minus 1 second. To issue the Prop command, perform these steps:
From a chat client, log on to the server as a chat administrator or chat sysop.
Type /prop <channel> <property> :<lag value>. For example,
/prop #mychannelname lag :2.
Clone Attacks A clone attack occurs when an attacker establishes several connections to a server from a single IP address and sends multiple, frequent messages 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. The Maximum IP Connections option is the setting to use in this situation.
Direct Client Attacks 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. By enabling IP/DNS masking, which masks a portion of each user's IP address or DNS host name, you can reduce the attacker's chances of success. 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, benglish@hr.oaktree.com is published as benglish@xxxxx.oaktree.com. If a user has no DNS host name, the server masks the last number of the IP address. For example, the address 192.168.2.200 is published as 192.168.2.xxx.
Sysops, channel owners, and channel hosts (including chat administrators) can see each user's full IP address or DNS host name so they can, if necessary, remove or ban users from Chat Service or a specific channel. Channel owners and hosts can see the full IP address or DNS host name only of users in their channels. Select the Enable The Masking Of IP Addresses And DNS Names check box on the Access tab of the user class's property sheet to enable this feature.
User Bans
User bans restrict individual users from accessing a specific chat community. If a user attempts to access a banned community, the user is refused. The user can be restricted by nickname, user name, or both. The chat community protected by the ban is identified by either the domain name or IP address. User bans are community specific, meaning that a user banned from one community may be able to access another community on your server.
To ban a user, navigate within the Exchange System snap-in to the chat community from which you want to ban the user, right-click the Bans container, point to New, and then choose Ban. As Figure 18-4 shows, you can ban a user based on nickname, user name, domain name, or IP address. You can also configure a time frame during which the ban will be active. These settings work the same as they do for user classes.
Figure 18-4. Ban settings for a chat community.
TIP
To ban an entire group of users from a chat community, create a group in Active Directory Users and Computers, add the user accounts to that group, and then ban the group.
You can control individual user access to a chat community in a number of ways. Here is a list all of the different ways to control user access to Chat Service; each is described elsewhere in this chapter.
- Limit the number of user connections
- Allow only authenticated users
- Impose restrictions on a group of users
- Ban individual users
- Disable all access to the chat community
- Disconnect users from Chat Service completely