Protocol Negotiation and Session Setup

SMB has a built-in mechanism that is used by the client and server to determine the other's capabilities so that a common protocol version can be established that the two will use for the network con• nection. The first SMB message that the client sends to the server is one of the SMB_COM_NEGOTIATE type. The client uses this message to send the server a list of the dialects it understands. The server selects the most recent dialect it understands from the client's list and returns a message to it.

The response the server returns depends on the type of client. The information includes the dialect selected and can include additional information, such as buffer sizes, supported access modes, time and date values, and security information. After the client receives this response, it can continue to set up the session by using the SESSION_SETUP_ANDX message type.

If the initial server response indicates that user-level security is being used, this message type can be used to perform a user logon. The client sets a value in the message header called the UID (user ID) for the account it wants to use. It also supplies the account name and password to the server by using this message type. If these values are validated by the server, the user can continue to use the UID to make subsequent accesses.

Other setup functions that are performed by using SESSION_SETUP_ANDX include the following:

• Set the maximum values for the size of buffers that will be used in the message exchange.
• Set the maximum number of client requests that can be outstanding at the server.
• Set the virtual circuit (VC) number.

If the VC passed to the server is zero and the server has other circuits open for the client, it will abort those services, assuming that the client has rebooted without freeing those services first. To properly close a session, the client uses the message type LOGOFF_ANDX, which causes the server to close all files associated with the user's UID.

Accessing Files

Other SMB message types are used to traverse the resource directory and to open, read, write, and close files. First, the user must connect to the resource by using the TREE_CONNECT message. The mes‑

sage includes the name of the resource (server and share name) and, for earlier clients that do not perform logons, a shared password. The server responds by sending the user a value called the TID (Tree ID), which will be used in SMBs exchanged for this connection.

After the connection has been established, several basic SMB command formats can be used to manipulate files and directories that reside on the share. For example, the CREATE_DIRECTORY message is used to create a new directory in the file share's directory structure. The client passes the pathname for the new directory, and the server creates the directory, provided that the client has the appropriate access rights or permissions. The DELETE_DIRECTORY SMB message can be used to remove a directory, again based on the functions allowed for the username.

Opening and Closing Files

The OPEN message is used by a client to open a file. The path for the file is given, relative to the file share root. The client specifies the access that is desired, such as read, write, or share. If the file is successfully opened, the server returns a File ID (FID) to the client, which is used to further access the file using other SMB message types; it is similar to a file handle, which most programmers will recognize.

The server also returns data to the client indicating the actual access that was granted, which is read- only, write-only, or read/write. The CLOSE message is sent by the client to tell the server to release any locks held on the resource fileheld by the client. After this message, the client can no longer use the FID to access the file, but it must instead reopen the file and obtain a new value.

When a client does not know the exact name of a file that it wants to open, the SEARCH message can be used to perform a directory lookup. This function enables wildcards to be used, and the server response can include more than one filename that matches the request.

Other IDS Features to Consider continue...

Monitoring and Privacy

Keystroke monitoring has not been a fruitful approach to intrusion detection. As with many other computer science endeavors, context-sensitive analysis of data is one of the most difficult reasoning challenges for a program. Therefore, no commercial IDSs rely on keystrokes for determining misuses or intrusions. If such a tool were to exist, how would you handle privacy issues?

Most companies own the intellectual property of employees and also legally restrict computer activities to only those approved by management. A common practice is to present this warning to all computers users as part of the normal login message. This does not mean that all managers in a company own all of the correspondence of all of the employees. Especially unclear is how to handle the conflict that arises between privacy and monitoring. For example, if your IDS does monitor keystrokes, then someone is capable of reading the e-mail of employees. Sure, the company owns the content of these messages anyway. But, what if the message is from an employee to a superior complaining about harassment on the job. Is this something from which an IDS might generate alerts or message excerpts?

Unfortunately, you should be worried about privacy and IDSs even though they do not perform keystroke analysis. What if someone is filling out a medical form online and enters words such as "attack," "weakness," and "confidential?" Many network sniffers would look for these as part of a standard set of watch words. Ideally, you could configure the sniffer to ignore these words when the user was in the context of a medical application online, but it's unlikely the tool supports this because it is a difficult algorithm to generalize.

System monitoring tools also require caution. Audit trail reports contain the full command and its parameters in most cases. Knowing that an employee is suddenly sending several mail messages to someone in personnel could be confidential. This situation particularly becomes a problem if the manager is receiving IDS usage reports (to look for misuse problems), and the employee is documenting improper behavior by that manager. In this particular case, the best advice is to document the problem on a home computer rather than risk discovery by unauthorized sniffers being used at your site.

By the way, these privacy problems are not limited to intrusion detection. In plenty of cases, developers use network sniffers to capture packets that are needed to debug a problem. Separating confidential information from test environments is the right approach for solving this dilemma. An interesting legend has gone around about how some user IDs and passwords from a reputable company found their way into one distribution of Crack when the software was tested in a production environment.

If you run a scanner and configure it to mail reports, verify your configuration so that you are not mailing the list of easily guessed passwords to everyone at your site, or even worse to your favorite newsgroup on the Internet. In some instances, someone mailed the output of a scan to a personal account outside the company, and the mail message flowed in the clear across the Internet. Remember, without encryption the Internet is like one big party line that many people share.

Finding New Attacks

Companies that build IDSs know the importance of keeping up with new attacks. Companies do this in several ways.

ISS recently has put together a talented team called the X-Force. This group spends a great deal of time uncovering their own exploits, as well as maintaining contacts in the hacker community. Secure Networks, Inc., also has a dedicated team of researchers that look for exploits, as did the WheelGroup (now folded into Cisco). These folks spend a good portion of their day looking for weaknesses in systems and networks. If you subscribe to BUGTRAQ, Best of Security, NT Security, and other security mailing lists, you'll see the names of some of these folks appear regularly. They also are frequent panel members at conferences such as DEFCON and Usenix Security.

Another group of ethical hackers operates as LOpht Heavy Industries. Once described as "rock stars of computer security," the LOpht is responsible for discovering well-announced weaknesses in products such as Kerberos V4 and Microsoft NT. The most famous output from the lab is the NT password cracker developed by two of the team's members. Hacking in a private laboratory because its fun and interesting is perhaps the best motivation for finding security holes in products. That's really why these exploit hunting teams exist.

Early hackers broke into systems because they were curious and wanted to learn more. Many remote attacks occur for the same reason today. Not everyone is out to damage your systems, although plenty of people enjoy doing so. Staying in touch with hackers is one way that companies know the latest exploits. Don't be surprised if you find a consultant who has a history of attempted break-in attempts or even a conviction.

Security newsgroups and mailing lists are other avenues for keeping abreast of holes in systems. Most of these groups are moderated. A common rule of thumb is to notify the vendor before posting the flaw. Moderators are generally good about ensuring this happens. Unresponsive software vendors have sometimes been caught in the awkward situation of not knowing about an exploit because the mail from the discoverer was somehow lost in the corporate maze.

Rich Media E-mails

Rich media e-mails go one step beyond the use of static or animated graphics in HTML e-mails, and give a richer experience through more complex animation, video and/or sound. Some refer to HTML as rich media, but more commonly the term is used to refer to e-mails with more dynamic or interactive content. A video can be streamed when the user opens the e-mail, or the message displayed in the preview pane and the video downloaded and displayed in real time — for example, Trailermail (www.trailermail.co.uk) is used to provide video trailers for movie companies. Alternatively, Flash animations can be integrated into the e-mail.

Many brands have experimented with rich media e-mail, but they don't seem to be increasing in popularity. There are several potential reasons why they have not been used more widely:

• E-mail, as with other digital media, tends to support impulsive behaviour — we don't want to wait for downloads unless the download is compelling
• Many corporate firewalls can block streaming media and, because of the high at work usage of e-mail, companies cannot risk reducing the visibility of their message
• Again in the corporate setting, e-mail recipients often won't want to be seen listening to or viewing a video clip by their boss, unless they control the media and turn on audio
• There is not a clear relationship between the incremental cost of rich media and the
  returns generated either through response or uplifts in brand awareness and favourability.

Owing to the technical issues of delivering rich media within the e-mail, increasingly companies are using an approach where the message directs the viewer to a web site to download or stream a clip. Of course, this means that the e-mail has less impact itself. If rich media is used in e-mail, it is more likely to be relatively simple — perhaps a flash animation — and is used to complement a text or static image-based message which will be effective even if the rich media element doesn't download.