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.

Using a Shadow Password File of Unix and Linux

To plug the password security hole presented by the / etc / passwd file, a technique called a shadow password file is usually used. This file contains the actual passwords, also in encrypted format. However, the shadow password file is not world-readable, and permissions are set so that only the root account can access this file.

On many systems, the name of the shadow password file is /etc/shadow. Check your documentation to determine the exact path on your system. Also note that on some older systems (and a few current ones), you'll have to load an extra component to install the shadow password file capabilities. Keep up-to-date by consulting your vendor's Web site.

The contents of this file also can vary from one system to another. However, the following format contains the fields used in most implementations:

username:password:last:may:must:warn:expire:disable:reserved

The following list describes these fields:

• username—This field is used for the same purpose as it is in the /etc/ pa s swd file. It is the login name for this user's account.

• password—The user account password stored in encrypted format.

• last—The number of days, since January 1, 1970, that the password for this account was changed.

• may—The number of days that must pass before the password for this account can be changed.

• must—The number of days after which the password for this account must be changed.

• warn—The number of days before the password expires to warn the user about the upcoming password expiration.

• expire—The number of days that must pass before the account password expires and the account becomes disabled.

• disable—The number of days, since January 1, 1970, that the account has been disabled.

• reserved—This field is reserved for future use.

As you can see, using a shadow password file gives you additional control over accounts, such as setting password expiration values. It also gives you informational fields (such as last and disable that can be used when managing user accounts.

The /etc/groups File

This file contains a list of user groups and a numerical value used to identify the group. The syntax for entries in this file is as follows:

groupname:grouppassword:groupID:username1,username2

• groupname—A name associated with the group. Using a meaningful name can help you simplify user administration.

• grouppassword—Yes, you can place a password on a group, but this is generally not done. Instead, this field is usually left blank.

• groupID—This is the group's ID number, which is used by the operating system to identify the group. It is often referred to as the GID. This number can range from 0 to 32,767, and the numbers 0 to 10 are generally reserved for system groups. For example, in most Unix implementations, the root user has a GID of zero.

• usernamel,username2 . . . —This is a comma-delimited list of members of the group. Separate each using a comma.

Users can be members of more than one group. If this is the case, the first group is the user's primary group, and the GID of this group is used when files are created or saved. Users can use the groups command to view the group(s) of which they are a member. The command chgrp can be used to change the current default group.

System Daemons and Services

Windows servers have background processes that perform many functions, called services. Unix systems also have background processes that work in a similar manner that are called daemons. Regardless of what you call them, these processes, which are called background because they do not require interaction with the keyboard but instead execute on the computer waiting to perform some function, can introduce security problems when they are not needed.

You should become familiar with the background processes on any servers in your network and disable those that are not needed. For example, on Unix systems, there are many background daemons associated with the TCP/IP suite of protocols. Some systems might need all of these, whereas some might need just a few or none of them. It might be that you do need these services. It might be that they need to be configured properly prevent their misuse. You should read the dumentation that comes with your Unix or Linux system to determine the capabilities that these daemons provide and disable them on systems that do no need them.

For example, tftp (the trivial ftp transport application) is a stripped-down version of FTP. It is com and usually can be easily implemented in an EPROM. For this reason, it is useful in some devices need to download operating software from a host. However, note that unlike FTP, tftp has no acc control mechanisms. This means that a username and password are not used. Because there is no authentication, this can be a real security problem if it is not configured properly, such that it can used only for its intended purpose.

On Windows servers, you can use two programs that are provided with the Resource Kits to install or run almost any executable program or batch file as a service. These are INSTRV.EXE, which can be used to install an executable, and SRVANY.EXE, which can be used to make other kinds of files into services. On a server that has several users logging in frequently, you might want to make it a regular part of your routine maintenance to review the services running on the machines and disable or remove those that are not installed by the initial operating-system installation or those that did not come from products you have applied to the system.

To do this, you will need to keep an inventory of what runs on each server, but this kind of inventory information can be useful for other purposes, such as when you need to reinstall a server that has been destroyed by a catastrophic failure.

Removing Dead Wood

Every operating system comes with default options installed that you might not be aware of unless you have read the documentation carefully. For example, default user accounts might be created

when you install the OS or later install a product. For example, the GUEST account in Windows operating systems is installed by default. You should always disable or remove this account. The Administrator account is also a vulnerable target because it is present on all Windows Server computers from Windows NT through Server 2003. You cannot delete this account, but you can rename it so that the hacker's job becomes more difficult. Also, you shouldn't use the Administrator account on a regular basis. Instead, create individual administrative user accounts for each system administrator trusted to perform these high-level tasks. Then put them into the Domain Admins group to allow these users to exercise administrator privileges, while maintaining an audit trail of the actual users who performed certain actions. You should always use separate administrative accounts for your domain administrators. Never use the same account for domain administration as is used for regular user functions. Administrators should be logged in with administrative accounts only when performing activities that require elevated permissions. You can also use group policies to further restrict what each user can do.

Regularly review the user accounts that exist on the network. Use the auditing features provided to determine when an account has not been in use for a long period, and if you can find no reason for its existence, disable it. Maybe someone in another department did not notify you when a user was terminated, or maybe an account was created for an expected new employee or contractor who later changed his mind and did not come on board. New accounts such as these are typically created with a simple password and can leave gaping security holes in your network.

Old programs and files that are no longer needed, or the use for which you are not sure, are also easy targets to cause security problems. As a rule of thumb, if it's not needed, back it up to tape and delete it! If a user finds that something she needs is missing, she will tell you!

When installing a new application product for a user, be sure you know the capabilities of the application. Don't install unneeded optional features that will not normally be used. Read the documentation!

Enforcing Passwords Security

It might not seem like an important thing to mention at this point, but you need to enforce a policy that makes users choose good passwords. And when you do that, you must decide what makes a good password for your environment. Simply put, a good password is one that is hard to guess. When you consider that a standard password-cracking technique used by hackers is to simply try every word in a dictionary, you can begin to understand that luck doesn't have a lot to do with penetrating a network. It comes mostly from lax security that allows doors that are easy to open.

Enforcing Good Passwords

When deciding how passwords are to be constructed, there are a few guidelines you can follow:

• Use more than one word. Multiple words "glued" together make a pattern of characters t is much harder for a simple password-cracking program to guess. Don't use words that natur go together. For example, Atlantabraves is not a good choice; Atlantayoko is a better choice. Never use a name of a celebrity or a popular institution.

• Use nonalphabetic characters somewhere in the password. This can be numeric ch acters or punctuation characters, provided that the operating system you use will permit the

• In Unix and Windows NT/2000/Server 2003 Server editions as well as Windows XP, passwords are case sensitive. If you use both upper- and lowercase characters in a p word, you can confound many password-guessing applications. Do not, however, substitute numeric characters that resemble alphabetic characters. One of the easiest things a password- hacker application can do is to substitute the letter "0" for zero. Don't fall for that one!

• Don't make passwords too difficult to memorize. The last thing you want is to have frustrated users writing down passwords so that they will be able to remember them. If you this happening, it's time to re-educate the employee. There are many methods in use today t can be used to provide "one password" for all applications on the network. You should inves gate these types of applications and, if appropriate for your network, justify the cost versus t cost of a network intrusion. Many of these systems involve smart cards and PIN numbers. Again, although this may be an expensive up-front cost, justify it by the value of your data.

• Use password history restrictions if the operating system permits it. This means the operating system keeps track of a limited number of passwords that the user has previou used and will not allow them to be reused within a certain time frame. A common practice is change your password when forced to do so and then to change it back to a value that you like and can easily remember.

Be sure that you do not create user accounts and assign them a password that never gets changed by the user. Most operating systems will allow you to set a password to be expired on its first use so that when a new user logs in the first time, he will be ruired to change his password.

Sometimes it is important to have a password that makes no sense whatsoever. In a highly secure environment this can make sense, in that you want something that is hard to guess. However, remember that when something is difficult to remember it usually gets written down somewhere, which can defeat the purpose of a password altogether. Unix has a command, passwd, that can be used to computer-generate a password for a user. For example, the command

passwordusername

displays a list of potential passwords that are generally difficult to guess. The user can select one from this list to use if he is having a difficult time thinking one up. The only problem with this method is in getting the user to memorize the password.

Password Policies

No user account, including one used by an administrator (or root for the Unix/Linux community), should ever be allowed to keep the same password for an extended period. A good idea for passwords is to require that they be changed every 30-60 days, depending on the level of security you need at your site. You also should enforce a minimum length for passwords. Most operating systems willallow you to specify this value so that users cannot change their password to one that is shorter than the size you require.

On Unix systems, you can set the password minimum length by specifying it in a field in the file /etc/default/passwd.

On Novell NetWare servers, you can enforce a minimum password length by modifying the object properties of the template object used to create a user account, or by modifying the properties of an individual user object for a particular user.

Depending on the particular operating system, you can enforce other restrictions on passwords or user accounts to enhance security on the network. Some of the capabilities you might find include these:

• Password expirations—A password should not be used indefinitely.
• Password history lists—This feature prevents a password from being reused within a specified period.
• Account lockouts—When a hacker is trying to use the brute-force method to guess a password for an account, you should be able to lock out the account automatically after a specified number of attempts within a specific time frame.

PasswordGrabbers

About the oldest trick known to those who would want to break into another user's account is the use of a program that imitates the operating system's own logon procedure. This kind of program generally is executed by someone who logs in using his own account on another's workstation. He thenruns a program that does nothing but wait until the unsuspecting user tries to log in. The program prompts for a username and password, mimicking the operating system in every respect. However, instead of logging the user on to the system, which the program is unable to do, it simply stores the password in a file and then generates a phony error message.

If the user is not too concerned about security, he will probably never know that he has been fooled. The user might think he has entered his password incorrectly and try again. The second time it will succeed because it is the operating system that is prompting the user this second time. The password grabber program has already done its job and it disappears.

The user who began this fraud simply retrieves the file, thus getting the password, and then can freely log in as that user and cause many problems when it comes to tracking down the real person who is abusing security. Because the perpetrator is now using someone else's username and password, he is difficult to catch.

Filtering on IP Addresses

To briefly review, the IP protocol is used by other higher-level protocols (such as TCP and UDP) to provide a connectionless best-effort data-delivery service. To do so, the IP datagram encapsulates the TCP or other protocol segment by adding source and destination addresses, port numbers, and other header information before sending the datagram farther down the protocol stack, where it is eventually transmitted on the wire bit-by-bit by the physical components of the network.

Routers can be configured easily to examine the contents of the IP header and drop packets that don't match a set of rules that the network or firewall administrator configures on the router. Perhaps the most obvious example is to filter out packets arriving from the Internet that have a source address that falls within the same network address range used on the internal network. Because such a packet, if it were indeed valid, would have to originate inside the network, it shouldn't be coming in from the outside! It is easy to forge IP packets so that the source address, as well as other header information, can be set to anything a hacker desires. A lot of programs are freely available on the Internet to do this.

When a packet with a source address is sent into your network, it's more likely that the destination server or workstation in your network will accept it as a valid packet, thinking it's coming from a user on the local network, and the packet will be processed as usual. Using this method, it's easy to get packets into your network and actually have them delivered, when they should not be.

This is only one example of a good reason to filter packets based on the IP addressing information in the packet header. Because addresses can be forged, and because it's not practical to list all the millions of addresses that are allocated to computers on the Internet and pick and choose, you need to be cautious when using this kind of specific filtering. For example, suppose your network becomes the subject of a denial-of-service attack. You can use a network analyzer to discover the source addresses of the packets, and quickly insert a rule in the router (or firewall product) database that drops all packets that come from the network from which those packets are coming.

Filtering Based on Protocols

In the IP packet, a field is used to indicate the type of protocol the packet is carrying data for. For example, if the IP packet is carrying TCP data, the protocol field in the IP head& is 6. If it's carrying an ICMP (Internet Control Message Protocol) message, the protocol number is 1. The capability to filter out certain protocols is useful because many of the protocols in use on the Internet were created many years ago when security was not as much of an issue as it is in today's commercial Internet.

Take ICMP, for example. The Ping utility makes use of ICMP packets to determine whether another host is reachable. An ICMP ECHO REQUEST packet is sent to the address of the host computer in question. If it receives the packet, the destination computer sends back an ICMP ECHO REPLY packet. Sounds simple and safe, doesn't it? Well, it is simple, but not necessarily safe. Inside your network, Ping can be a useful tool for quickly determining that somewhere along the network path something is wrong and a computer is not reachable, whether the destination you are pinging is inside your network or on the Internet.

However, just as you wouldn't give out your credit-card number to a stranger, it's not a good idea to give out any information about your network, especially the addresses of the computers on the network, to an outsider. And, that's exactly what the ping command can do. It's easy to write a program that sits back and cycles through a range of IP addresses, sending out ICMP ECHO REQUEST packets and looking to see what replies come back. This saves a malicious hacker time because he now knows that an IP address is in use and can proceed to further try to intrude and compromise the system. Because automated tools are available for continuing the hacker's probe, it's imperative that you keep your network address information secret.

If you've ever received those boring telemarketing calls during the early evening hours, you can understand how this works. The telemarketers just cycle through phone numbers until they get someone to pick up the phone and answer. Allowing ICMP ECHO REPLY packets to respond to requests from outside your network is the equivalent of picking up the phone. Although you can hang up on a telemarketing call, after a hacker has your network address, she can always try back later when you're not around and use a wile variety of tools to probe your system to determine what is needed to get inside.

For this reason, it's usually a good idea to block incoming ICMP ECHO REQUEST packets. You probably don't want to block outgoing packets of the same sort, because they serve a useful purpose. You can allow users inside your network to Ping other servers on the Internet. For example, suppose you want to place an order with a business that has a website, yet it doesn't pop up in your browser when you try to get to its home page. You can use Ping to determine whether the business's computer is on the Net and functioning, and then from there start your troubleshooting efforts to find out why you can't bring up the business's Web page. If you Ping the site and get no response, you can be sure that either it's down or somewhere along the network path a router or another device is not letting traffic get through.

The same goes for you if you offer a service on the Internet. However, in such a case, you should make sure that your Web servers are highly secured and located on a network segment that can limit the damage should these servers be compromised. This network segment is called a demilitarized zone (DMZ).

Another utility that uses ICMP is Tracert. This command probes the network path and returns a list of all the routers and other intermediary devices it passes through to get to a destination address. Again, this is a useful tool when used properly, but you should block this sort of packet at your firewall. Do you want outsiders to know the addresses of routers and other devices on your network? After an outsider has the address and knows that a computer is online using that address, it's easy to use one of the many hacker tools available on the Internet to begin breaking into the computer.