Determinación de los contenidos pseudototales

HyperText Transfer Protocol (HTTP) is the protocol of the World Wide Web. Obviously, HTTP is designed for public access so security is of paramount importance—so much so that HTTP security is the subject of its own chapter in this book. In this chapter, it’s presented as a pure file sharing mechanism without discussing its primary context on the Web.

Under the hood, HTTP is much like FTP with a few extensions. Like FTP, HTTP is a file transfer protocol, not a file sharing protocol, so it’s not appropriate for multi-user write

access. This is not an issue, however, since the Web uses a pure publication mechanism where clients don’t normally expect to be able to modify web pages.

Note The HTTP WebDAV (Web Distributed Authoring and Versioning) extensions add semantics to allow for multi-user file locking so that the Web can be used as a true file- sharing protocol. WebDAV was developed to allow easier website editing on live servers by multiple authors, but it is now being incorporated into office programs to allow traditional file sharing over the Internet.

The primary extension that makes HTTP different in the minds of users is the concept of the embedded link that browsers can use to automatically request new documents. Links contain the full, globally unique path to the document, and when a user clicks on them, the browser requests the document from the server. The link request is actually determined and negotiated by the browser—a browser could be configured to run using anonymous FTP and work essentially the same way that HTTP works.

Links aren’t what makes HTTP special. HTTP’s PUSH and GET semantics that allow form submission and the passing of parameters between pages, as well as the extensions that allow server-side session information to be retained between page loads are what makes HTTP different than FTP. With an FTP-based hypertext system, there would be no method to submit a form, except to write a file back to the FTP server—and that would come with all the

problems that anonymous writable FTP sites have.

Configuring a Unix web server is easy: Download the Apache web server from www.apache.org, install it according to the instructions provided with it, and edit the

/etc/httpd.conf file to create the root of the www service. From that directory, the files within it are available publicly (usually, although TCP Wrappers and most web servers allow you to limit which machines can attach to the server using their own mechanisms). Although other web servers exist, Apache has stood the test of time and stood up to literally billions of hacking attempts, with few real exploits having succeeded against it. Apache is also among the fastest web servers, and it has reasonably good default security mechanisms to keep novice webmasters from making simple security mistakes.

HTTP Security

There is no protocol more public than HTTP. You are inviting the world onto your server when you use HTTP. Because every web server program written has been exploited at one time or another, you should assume that hackers will be able to exploit your web server if they want to. HTTP security is so critical that it is covered in the next chapter.

Samba is an open-source implementation of Microsoft’s Server Message Block protocol, also called the Common Internet File System. SMB is the file sharing protocol used by Windows, originally in Local Area Networks. Despite its LAN origins, SMB works surprisingly well over the public Internet. When properly used, it can be made secure enough to use on the public Internet. Aside from Samba, commercial SMB/CIFS servers and clients are available for most versions of Unix. SMB runs on all versions of Windows, MS-DOS, OS/2, and Macintosh computers natively as well. After FTP, SMB is the closest protocol there is to a universal file sharing protocol.

SMB is a true file-sharing protocol, with a rich enough semantics to allow multi-user write locking. To attach to an SMB server from Unix you can use smbclient, which is much like a standard command-line FTP client. If you’re using an open-source Unix that has SMB support compiled into the kernel, you can use the much easier smbmount and smbumount commands, which work exactly like mount and umount work for NFS exports.

Note For Windows machines, SMB is built right in. By simply specifying a path to the server in the form \\sambaserver.mydomain.dom\sharename, a user can provide logon

information and begin using the file system. Windows will attempt a “silent logon” behind the scenes using the user’s logon credentials, so if the Samba server has a matching user name and password, the logon will be seamless. Otherwise, Windows will prompt for a username and password combination to allow access.

Samba Security

To avoid en-masse the problems involved with sending UNIX UIDs across the network (as well as to ensure Windows compatibility), SMB transmits user names and passwords between the client and the server for authentication. You can configure SMB to use clear text or

encrypted passwords; most Unix installations use clear text passwords because it’s easier and because early versions of Samba did not support encrypted passwords; also, each new version of Windows seems to break Samba’s password encryption mechanism, and it takes a few months for Samba to catch up.

Samba is configured by making changes to the /etc/smb.conf file. In this file, you establish shares, or directories that SMB will expose to SMB clients. You can specify an unusual number of security options for a Unix file sharing protocol, including what access various users will have, what the default permissions for created files will be, and whether writing is allowed.

share

A portion of a file system that the SMB service (server.exe in Windows, samba in Unix) exports for access by SMB clients. Access to the share can be configured on a per-user or per- group basis.

Interestingly enough, Samba doesn’t use local Unix accounts for SMB security; rather, the Samba daemon authenticates users against a separate list of users. This means that Samba users need not have Unix accounts on the Samba server, but it also means that individual file system permissions can’t be used to secure files on an individual basis. In practice, this means that Samba user accounts can’t be exploited by testing them against other protocols or trying to log in directly with them using Telnet or SSH, which significantly improves security.

If you set up a public Samba server, use the same caution that you would with an FTP server. Set up a separate host inside your DMZ to transfer files rather than making an internal

machine available on the Internet. Don’t allow connections originating from that machine; rather, connect to it from within your network to move files off it. Be certain to encrypt passwords. Use a dedicated firewall to filter connections to the server, and use IPChains or IPTables to filter all protocols except ports 135, 137, 138, and 139 directly on your Samba server.

Note Windows 2000 allows direct SMB over TCP (without NetBIOS) on port 445. Remember this when you’re configuring your firewall policy.

Overall, because of its foreign-OS origin and high code quality, Samba is the most secure commonly used file sharing protocol for Unix. Prefer it to NFS for LAN servers, and consider it over FTP for public servers.