Using the SMB/CIFS Protocol on Non-Microsoft Clients: Samba

SMB/CIFS is a protocol that is highly entrenched in the Microsoft world of operating systems and networking products. It makes sense, then, that there would be a way in which these workstations and servers could be integrated into a Unix/Linux environment without a lot of difficulty. The answer to this problem is called Samba, which is a set of products that provide for SMB conversations between SMB servers, such as Microsoft Windows operating systems, and those that do not use it natively,such as many different variants of Unix or Linux systems. In addition, Samba has been ported to several other popular operating systems, including OpenVMS.

Samba was originally developed by Andrew Tridgell and is now maintained by him and other developers (the "Samba Team") on the Internet.

From this Web site you can choose a mirror Web site for your country, and then you can view the documentation for Samba and download the most recent version. The software is freely distributed under the GNU public license.

You can configure Samba servers on your Unix boxes to enable high-performance machines to beused as file servers on the Windows network. You can still manage the servers using Unix file administration procedures, and yet to the client computers, the shares appear no different than those offered by other Windows-based file servers.

Troubleshooting a Samba server can be made easier by starting the Samba server software using the - d parameter to specify a debug level (from 1 to 100), which will cause more output messages, depending on the level you specify.

You can also use a LAN analyzer to view the sequence of exchange of SMB messages between server and client. Available as a download from the Samba home page is an extension to the tcpdump utility, called tcpdump-smb. You can use this to capture smb packets and decode the header information.

The Common Internet File System (CIFS)

CIFS is intended to be a replacement, or an upgrade, of the SMB protocol. Design considerations include making it platform-independent. While SMB resides in the NetBIOS legacy environment, CIFS runs on top of TCP. Other improvements over SMB include the following:

• Unicode filenames are used. Because the Internet is global, it's helpful to be able to encode char acters that support multiple languages.
• Service is automatically restored after a network disruption.
• CIFS is not proprietary to Microsoft. It is an Open Group standard (X/Open CAE Specification C209). It has also been proposed as an Internet standard to the Internet Engineering Task Force (IETF). This is an improvement over the earlier SMB protocol.
• DNS is used to translate between computer hostnames and IP addresses.
• Both share-level authentication and user-level authentication are supported. With user-level authentication, the user must be authenticated (using a username/password valid on the server) before access is granted.
• CIFS has been optimized to make communications across a slow link—such as a dial-up modem—possible.
• CIFS is basically an enhanced version of SMB and still uses server message block messaging. Better security and the use of DNS are necessary additions if the protocol is to be used on the Internet.

Printing Protocols and Printing Languages

A printer language is not the same as a printer protocol. For example, PostScript and PCL (Printer Control Language) are languages that describe how a document is to be rendered into the final printed product by the printer. When a printer is directly connected to a printer port on a computer, the printer language is important and is used by the software driver to format the information being sent to the printer.

A printer protocol, however, is used to send the formatted job, both data and instructions compiled using the printer language, to the print device. A few protocols will be detailed here that are more specific in their use and implementation; that is, they generally are used for communicating with a printer.

Several protocols are used for network printing. Some are proprietary protocols used by only one computer or network operating system (NOS). Others, such as 1pr/lpd—which was first developed for use on Unix systems—have been implemented in many environments. Data Link Control (DLC) is an IBM protocol that has been adapted for use on many printers although it is not used much today.

Also covered is the newest printing protocol: the Internet Printing Protocol (IPP), which was created by a working committee of the Internet Engineering Task Force (IETF). Development is underway for standards to further define this new protocol. You will find, however, that both Windows 2000/2003/XP and NetWare 6.x already support IPP. Novell even sells its iPrint as a separate product that can be used in a non-NetWare environment.

Using Ipr/lpd and the TCP Stream Protocols

TCP/IP was originally developed for the Unix operating system (OS), of which there are several flavors. Depending on the version of Unix (as well as Linux) running on a workstation or server, you will find that TCP/IP printing falls into one of two major types:

• BSD (Berkeley System Distribution) Spooling System
• SVR4 (System V, Release 4) Printing System

The BSD system uses the 1pr (line printer remote) program to send files to printers. The printers can be connected to a network, or to a computer. Whichever way, the 1pd (line printer daemon) receives these print requests and interacts with the Ipr to send the print job to the printer. The / et c/ p r int cap text file is used to set up characteristics for each printer. The SVR4 Unix system uses the 1p (line printer) program and the 1psched daemon (printer scheduler) to print files. Although the SVR4 system is considered more sophisticated because it has several utility commands for managing the system, the BSD system probably is easier to manage in a networked environment.

When using either of these methods, the actual print commands and data are sent to the printer in the payload section of a TCP/IP packet.

Although all Unix and Linux systems support TCP/IP printing, many support other protocols as well. For example, Red Hat Linux can also be configured to use SMB (Server Message Block) to connect to a Windows server (or a Unix/Linux computer configured to offer printing services using SMB).

The 1pr/lpd protocols work well, but are mostly used by older operating systems.

TCP/IP stream sockets the Unix provide yet another way to use TCP/IP to connect to a printer. Streams are a two-way communication TCP/IP session between the computer (or print server). When using TCP/IP streams, you need to specify a port (also known as a socket in Windows terminology). Thus the address of the networked printer, paired with a port number, provides a unique address so that the data exchange can be accomplished.

Data Link Control Protocol (DLC)

For all practical purposes, DLC is rarely found anymore within today's networks, although it might still be found on legacy systems. This IBM protocol was widely used during the early days of networked printing, as well as for other applications. However, more robust protocols, such as TCP/IP, have made this protocol a less desirable solution for network printing.

The DLC protocol was developed by IBM primarily for use in connecting to mainframe computers as part of its Systems Network Architecture (SNA) specifications. DLC can also be used to establish terminal sessions with AS/400 computers. In addition to the HP Jet Direct card, you will find that other vendors also make network cards for printers that can use DLC. For example, the Brother NC-600X and NC-2010h network cards both can be used for this purpose. However, you'll find that DLC no longer is present in Windows systems starting with Windows) XP.

Physical Security Measures continue...

Novell NetWare provides this functionality by giving the user a logon to the network that is controlled by the Novell Directory Services. Each user is represented in the directory by a User object, the properties of which specify information about passwords and connections.

The Unix operating system does not use the concept of a domain. Instead, each Unix host maintain a password file that stores information about each user, including an encrypted password. To access resources on other network hosts, the Unix user must either log on when accessing the computer or use a proxy mechanism. TCP/IP utilities such as FTP and Telnet often send user passwords across the network in clear-text format and are easy targets for interception.

The Unix remote utilities, usually called r-commands because they all start with the letter r, are use to perform ordinary network functions such as copying or printing files or logging in to a remote s tern. This is very useful in the network environment in which a user performs functions on many( ferent machines. These utilities are not necessarily good when looked at from a security standpoint however. Although the user must have a valid user account on the remote hosts on which these co mands execute, the user does not have to provide the password.

Instead, an entry in the /etc/hosts .equv file or the. rhosts file on a remote computer is what deter mines access. The remote machine trusts the computer on which the user executes an r-command if can find an entry in either of these files for it. Each entry in the /etc/hosts . equiv file contains a hostname and a username, to identify users and the hosts that are allowed to execute these commands without providing a password. The assumption is that if you have logged in to the remote host, you have already been authenticated. The . rhosts file works in a similar manner but resides in user's home directory. The remote users entered in this file can perform functions based on the account associated with that user.

Although this sounds a lot like the Windows NT/2000/Server 2003/XP trust mechanism, it is not. It is quite easy to impersonate a remote node and gain entry into a Unix/Linux system by using the r-commands.

Resource Protections

After a user has been authenticated by the erating system, the next step to access a resource is for check to be done to see whether the resource has any access controls placed on it. Typically, an open rating system will grant access to a resource, such as a file, by granting users the right to do the folioing:

• lRead the file

• Write to the file

• Execute the file

• Take ownership of the file

• Delete the file

These concepts also can be extended to resources such as printers and modems. When granting these rights, most operating systems also enable you to specify which rights are applied to users or groups of users. For example, Windows NT enables you to group users into local or global groups. When you set the access controls on a file, you can specify the access rights by group. Using this method, one group of ordinary users might be able to read a file, while a group of users that manages the filemight be granted read and write access, as well as delete access to the file. To prevent programs from being run by unauthorized users, the execute right can be granted or denied to a user or a group of users.

It is important to understand the features of your operating system that pertain to granting rights or permissions. Rights generally enable a user to perform an action. Permissions are placed on resources and define who can access and what kind of access can be made of a resource.

After the Fact: Auditing Use

As you may be aware, there are auditing tools you can use to keep track of resource use, both attempted and successful logon attempts. Here it is important only to note that it is not enough to organize users into groups and grant them resource permissions throughout the network. A large user base, combined with multiple servers that hold valuable resources, makes it difficult at times for an administrator who is not familiar with the information resources provided by a specific server to understand the permissions needed. For example, a new user in the accounting department might or might not need access to accounts receivable files or accounts payable files. They might need access to one or the other or maybe both files. A manager in thatdepartment would probably be the likely person to make the decision about what files the usershould be able to access.

However, if the user is placed into a group, which is generally done to make administration easier,, compromises sometimes happen, and the user might be granted access through the group to resources that they do not need to access. Another reason is that sometimes mistakes are made. It is a fact of life that no one is perfect and that no system for allocating resources is going to get it right 100% of the time. When users are granted the capability to read a file, you can be sure, if the data contained in it is interesting enough, that they will do so.

Indeed, even if a user does not have appropriate access rights to a file, sometimes the user will try to get at interesting information anyway.

For these reasons, a good operating system provides auditing controls that enable you to look back after a security breach to try to determine who did what and where they did it. Unix (and its variants, such as Linux), Windows NT/2000/Server 2003, and Novell all provide features that enable you to record both successful and failed attempts to access resources. They all do it in different ways, and many of these auditing and security features are not enabled out-of-the-box; so if you have multiple operating systems on the network, it will be important that you understand each of them so that you can best enable and use these capabilities.

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.

Sun Network Information System

NIS is used on Unix networks to keep important system files, such as the password file, synchronized among a group of servers. Remember that on Unix systems, each server has a password file, a user group file, and other important files that are managed locally on each server by default. This is similar to using a Windows computer in a standalone manner where each Windows computer has its own user account database.

NIS uses a database of maps that contain entries for the files the system administrator chooses to keep synchronized. For redundancy purposes, a master NIS server can be used along with slave NIS servers that receive updates from the master server.

SFU version 3.5 contains a component that can be used to allow a Windows Server domain controller to operate as a NIS server. The Windows server can operate as either a master or slave NIS server. However, if it is to operate as a slave server, the master NIS server on the network must also be a Windows server. This is due to the way NIS is implemented in Windows Server: The information that Unix NIS servers store in a map database is stored in the Active Directory. The Active Directory schema is extended to include a class for each NIS map. Then objects are created based on this class for each map entry.

NIS uses its own protocol to send updates from a master NIS server to slave servers. The Active Directory, on the other hand, has its own method for replication information to other Active Directory replicas. The two methods are not compatible. That's the reason why a Windows domain controller cannot be made a slave NIS server to a Unix master NIS server. However, Microsoft does provide support for the NIS protocol so that Unix systems can become slaves to a Windows 2000 master NIS server! So, if you decide to integrate NIS into the Windows 2000 portion of your network, you'll have to make a Windows domain controller the master NIS server.

The advantages of using NIS should be obvious. On Unix networks, NIS relieves the administrator of having to manually coordinate important system files on multiple servers. By incorporating the SFU NIS server into the network on a Windows domain controller, you can use the tools designed around the Active Directory to manage not only your Windows users but also users on your Unix systems.

Another advantage to using a Windows-based NIS server is that the Active Directory is a hierarchical database, whereas the NIS database format is a flat namespace. You can place NIS maps into any container in the Active Directory, such as an organizational unit (OU). You can probably figure out from this that you can support multiple NIS domains in the same Active Directory database.